Repository navigation
[Feature]: add todo support for v2 #42421
Description
Summary
In OpenCode V1, the model could write and read its native TODO list through the todowrite and todoread tools (the list shown in the TUI). In V2 (0.0.0-next-17403), those tools are no longer exposed to the model: the runtime tool catalog contains read, write, shell, edit, patch, glob, grep, question, skill, subagent, webfetch and websearch, but no TODO tool, and there is no /api/todo endpoint. Agents can therefore no longer write their TODO list, which breaks workflows that relied on it (an agent asked to keep its list up to date reports the tool is absent from its function catalog).
Environment
- opencode version: 0.0.0-next-17403
- OS: Linux 7.0.0-28-generic (linux x64)
- Terminal: TERM=xterm-256color, COLORTERM=truecolor
- Shell: /bin/bash
- Install/channel: next
- Active plugins: agy-proxy, kt-directives, kt-todo-rappel, vision-helper (local plugins under ~/.config/opencode/plugins/)
Reproduction
- Start
opencode2. - Ask an agent to write its TODO list with the native TODO tool (
todowrite). - The agent reports the tool is not among its available functions.
Expected Behavior
The model should be able to write and read its TODO list, as in V1 (todowrite/todoread or an equivalent).
Actual Behavior
No TODO tool is exposed in the runtime, and GET /api/todo returns nothing. The string pipeToDoReadWrite appears in the binary, but no public tool or endpoint surfaces it.
Additional Context
The V1 to V2 migration guide lists only the server API and the plugin API as intentional breaking changes, and does not mention removing the TODO tool, so this looks like a beta compatibility regression rather than an intentional removal. Workaround currently in use: the agent keeps its list in a plain file instead.
Activity
github-actions commentedon Aug 13, 2026
This issue might be a duplicate of or related to existing issues. Please check:
If your issue is specifically about V2 breaking the behavior that was fixed/present in V1, it may be worth referencing those for context.
opencode-agent commentedon Aug 13, 2026
This is intentional in V2. The TODO tools are not currently planned.
JeanRomain commentedon Aug 15, 2026
Any reason for the removal of the todo tools ?
sachahjkl commentedon Aug 23, 2026
Made a little replacement/alternative
https://github.com/sachahjkl/opencode-backlog
rekram1-node commentedon Aug 23, 2026
we removed it because it slows agent down and we haven't noticed significant performance improvements from it's existence
hjohn commentedon Sep 4, 2026
@rekram1-node So, after a compaction, the model forgets about all todo's... it had to resort to querying the TODO list from the sqllite database directly thanks to the removal of the todoread tool. Surely this can't be intended?
docs: confirm todo-tool removal from opencode V2 is permanent
rubin55 commentedon Sep 18, 2026
@rekram1-node I think this really sucks; I used the todo in complex, long sessions, to keep track of where we are. This is now "invisible". The agent might have a todo-plan, but I need to ask it to show it, it does not show up in de sidebar.
I really think this is an omission, please restore it.
savonarola commentedon Sep 22, 2026
TODO was never for "significant performance improvements", it was for control and convenience.
Removal is an obvious downgrade, sorry for opencode following the "just tell the agent what to do" hype
miros commentedon Sep 22, 2026
Please focus on needs of users.
This was a very important and useful UI feature. How the user is supposed to follow what is happening in the session?
afriemann commentedon Sep 22, 2026
shameless plug for another todo plugin with working TUI and the same tool API (didn't want to change my custom instructions around todowrite): https://github.com/afriemann/opencode-todo/
jordiparra commentedon Sep 26, 2026
Agree on this one. Even if it has a cost and no tangible output impact. It is a UX functionality that is super useful in long sessions to easily see what's the progress.
14 remaining items
youvegotmoxie commentedon Oct 12, 2026
I hope this comes back because it's one of the big QoL features that made Opencode stand out. I didn't even know it had it until the first time an agent randomly used it. Since then I've integrated it into my workflow.
dr1ss commentedon Oct 12, 2026
I agree. One of the main reasons I used OpenCode was the todo list—it helped me track progress on complex tasks. When you have multiple tasks running across multiple projects, it makes it easy to remember what’s happening with each one and where it stands.
diogocnunes commentedon Oct 12, 2026
Please! Bring it back!
Animo78 commentedon Oct 13, 2026
I agree with bringing it back
at least let it be a plugin, the user can enable or disable.
Now in endless sessions I have to cancel the session, ask what the f* you doing and pause, then wait for an answer.
Which is annoying and cost even more time and tokens.
morpheus9393 commentedon Oct 14, 2026
Making it a setting (or a plugin) that can be enabled/disabled is a good idea! So everony can choose what he prefers.
smart-trust commentedon Oct 14, 2026
It would be fine to remove the
todowritetool if the todo sidebar actually worked. but it doesn't update - so it was the only workaround to a major bug. any team working without a kanban/todo board is dysfunctional. I suggest the opencode team try to work without consulting any such capability in their next sprint. when the sprint fails miserably, you will finally understand your own users and this flood of comments.morpheus9393 commentedon Oct 14, 2026
Yes, someone who removed a to-do list tool from a coding agent has probably never seriously developed software themselves.
gburke-ppb commentedon Oct 16, 2026
Any ETA on when this might be re-added?
Gibbz commentedon Oct 19, 2026
ive upgraded a machine to v2, and lost todo! Ugh, how do i go back to the old version? is there a downgrade command?
Why not keep the feature disabled by default, then those that want to use it can...
rekram1-node commentedon Oct 19, 2026
Will be added shortly
venx-ecosystem commentedon Oct 21, 2026
Thanks for bringing back the native TODO functionality in V2 and for the work on #56947 and #56948. I appreciate the effort to restore the "todowrite" tool and render TODO updates in the TUI timeline and sidebar.
I would like to request equivalent TODO support in the browser-based Web UI.
Problem
With "experimental.todo" enabled, the native TODO functionality can be restored, but enabling the feature alone does not provide the same user-facing TODO visibility in the Web UI as the recently merged TUI implementation.
I use OpenCode through a browser-based interface, where being able to see the agent's current plan and track progress is particularly important during long-running, multi-step coding tasks. Without a visible and reliably updated TODO list, I cannot easily tell which steps are pending, which task the agent is currently working on, or whether the agent has actually completed the planned work.
PR #56948 adds TODO rendering to the TUI timeline and sidebar. However, its scope does not include the Web UI. Could the equivalent Web UI implementation be tracked as part of this existing feature request or as a dedicated follow-up?
Requested implementation
Render native "todowrite" calls as dedicated, readable TODO cards instead of showing them only as generic tool calls.
Each card should display the task items and their statuses, including:
The timeline should make changes understandable without requiring users to inspect raw tool arguments or read the agent's textual summaries.
Provide a persistent, visible summary of the latest TODO list for the currently selected session, following the behavior introduced by #56948 as closely as possible.
The list should remain visible while the user reads the conversation or inspects tool output. Completed tasks should be represented clearly, rather than making the panel disappear immediately when the final item is completed.
When the agent creates or updates its TODO list, the Web UI should reflect the change automatically, without requiring a manual page refresh or a new user message.
Please use the underlying structured TODO state and the appropriate server/client event or API mechanism, rather than attempting to infer TODO state by parsing the assistant's natural-language responses.
The displayed list must correspond to the session currently being viewed. Switching between sessions should load the appropriate TODO state and must not leave the previous session's list visible.
Cleared lists, failed TODO updates, session changes, and applicable history operations such as revert or compaction should be handled consistently with the underlying TODO behavior.
The Web UI implementation should respect the existing "experimental.todo" setting and work with the native V2 TODO implementation. It should not require users to install an unrelated community plugin simply to see the built-in TODO list.
Please include coverage for timeline rendering, sidebar state, live updates, session switching, and empty or cleared TODO lists so that the feature remains reliable across future Web UI changes.
Expected result
When "experimental.todo" is enabled, users should be able to use the native TODO tool and see its current state directly in the browser-based Web UI, with functionality comparable to the TUI implementation in #56948.
To avoid scope ambiguity, this request is specifically about rendering the existing session-level TODO functionality in the Web UI. It is not a request for a separate project-wide task-management system or a new external TODO service.
Could you confirm whether Web UI support is already planned as a follow-up? If not, I would appreciate this being tracked explicitly, since the restored backend functionality and the TUI rendering are valuable, but they do not fully solve the problem for users who work primarily in the browser.
Thank you!
pumello commentedon Oct 21, 2026
Thank you for bringing the Todo tool back @rekram1-node and for your work on this excellent open source project 🙇