Repository navigation
OpenCode 2.x TUI becomes partially unresponsive while agent continues running #53165
Description
Description
Description
While running a very long-lived OpenCode 2.x session, the TUI entered a partially unresponsive state.
The agent/model is still continuing to work in the background, so this does not appear to be a complete application freeze. However, most interactive keyboard controls have stopped functioning and I am unable to interrupt or navigate the application normally.
The UI remains stuck showing thinking with the activity indicator/spinner in the lower-left corner.
Important session context
This is an unusually long-running session and may be relevant to reproducing the issue.
At the time the TUI became unresponsive, the session had approximately:
- 20 hours of continuous runtime
- 521 million tokens processed
- 3,474 turns
The session is intentionally designed to continue running. This is not a case where I expected the task itself to finish.
The problem is that after this extended runtime, the TUI became partially unresponsive even though the underlying agent continues operating.
This makes me suspect there may be some long-session state accumulation, TUI/input degradation, resource leak, event queue issue, or session-size-related behavior involved.
What still works
While OpenCode is in this state:
- I can scroll vertically through the conversation normally.
- I can resize the terminal window.
- The UI redraws correctly when the terminal is resized.
- I can see evidence that the agent is still doing work in the background.
- The underlying request/session continues running.
- The application does not appear to be completely frozen.
What stops working
Keyboard commands appear to stop being handled correctly.
I have tested:
Esc— does not interrupt/cancel.Ctrl+C— does not interrupt/cancel.Ctrl+Q— no response.Ctrl+P— no response.- Attempting to create/open another tab/session — does not work.
- Other normal TUI navigation/actions appear unavailable.
The concerning part is that the agent continues processing and consuming tokens while I no longer have a reliable way from the TUI to control or interrupt it.
Observed behavior
The screen continues to show:
thinking
along with the activity indicator in the lower-left corner.
Initially this looks like OpenCode has frozen, but the backend is clearly still working.
Scrolling remains responsive and terminal resizing/redrawing remains functional. This suggests the process and rendering loop are not completely dead.
Instead, it appears that keyboard input handling, command dispatch, cancellation handling, or some portion of the interactive TUI state has stopped functioning while the active agent loop remains alive.
Expected behavior
OpenCode should remain usable even for extremely long-lived sessions.
Specifically:
Escshould reliably cancel or interrupt the current operation.Ctrl+Cshould provide a reliable emergency interrupt mechanism.- TUI shortcuts should remain responsive regardless of session duration.
- I should be able to navigate or create sessions/tabs where supported.
- The UI should accurately reflect the current execution state.
- A long-running agent should not cause interactive controls to degrade over time.
- The user should always retain a reliable way to stop an active request.
Steps to reproduce
I do not yet know whether session duration or session size is required to reproduce this, but my observed sequence was:
- Launch OpenCode 2.x on Windows.
- Start a long-running agent session that is intentionally designed to continue operating.
- Allow the session to run for many hours and thousands of turns.
- In my case, the session reached approximately 20 hours, 521 million processed tokens, and 3,474 turns.
- OpenCode continues displaying
thinking. - Normal keyboard controls eventually stop responding.
- Press
Esc— no response. - Press
Ctrl+C— no response. - Press
Ctrl+QorCtrl+P— no response. - Attempt to create/open another tab/session — no response.
- Scroll vertically through the conversation — scrolling still works normally.
- Resize the terminal — the interface redraws correctly.
- Observe that the agent continues processing in the background.
Environment
- OS: Windows
- OpenCode: 2.x, latest available version at time of testing
- Model backend: OpenAI-compatible local backend
- Session runtime: approximately 20 hours
- Turns: approximately 3,474
- Tokens processed: approximately 521 million
- Session type: intentionally long-running / continuous agent workload
I can provide the exact OpenCode version and debug logs if needed.
Additional notes
I would describe this as a partial TUI/input failure rather than a complete OpenCode freeze.
Rendering still works. Scrolling still works. Terminal resize/redraw still works. The agent itself still works.
What appears to fail is the interactive control path.
Given the unusually large session size and duration, it may be worth checking for:
- accumulated TUI/session state
- input event queue issues
- keybinding/input handler failure
- memory or resource leaks
- rendering state growth
- event-listener accumulation
- very large conversation/history behavior
- cancellation handler degradation
- session-size-related performance issues
The session is intended to remain running indefinitely, so maintaining reliable interactive control over long-lived sessions is important.
The immediate issue is that the agent can continue consuming compute/tokens while the user loses the ability to interrupt it from the OpenCode UI.
Plugins
No response
OpenCode version
2.0.22
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
arittner commentedon Oct 27, 2026
I am experiencing a similar partial UI freeze with OpenCode 2.1.4 on Windows, using Windows Terminal.
After approximately 30–50 minutes of work, the terminal stops responding to keyboard and mouse input. The window title shows “Not responding” (when I click on the terminal window it gets half-transparent). The freeze can last many seconds, sometimes one to two minutes, before the interface becomes partially responsive again. The freezes then recur and become more frequent.
The agent appears to continue working while the interface is unresponsive. I can still see indications of ongoing agent activity.
An important difference from the original report: scrolling also stops working in my case, and other open Windows Terminal windows become unresponsive as well, including a second, separate window.
Important session context
What still works
During the affected periods:
What stops working
During a freeze:
I have not separately verified the behavior of each cancellation shortcut, such as Esc or Ctrl+C, during a freeze.
Observed behavior
CPU usage remains low during these incidents. Overall system memory usage was approximately 20 GB out of 32 GB. This is total system memory usage, not a measurement of the OpenCode process alone.
Expected behavior
Steps to reproduce
Environment
Troubleshooting and comparison tests
Additional notes
The fact that multiple Windows Terminal windows become unresponsive may be relevant to distinguishing this from a failure limited to OpenCode’s keyboard handling. I have not established the underlying cause.
opencodejr commentedon Oct 27, 2026
Thanks for the detailed report! Losing Esc/Ctrl+C while the agent keeps running is definitely something we want to understand. Reproducing a 20-hour session is hard, so a few details would help us narrow it down:
opencode --versionand how you installed it (npm, installer, etc.). If you can, please also check whether it still happens on the latest 2.x release.opencodeprocess(es) in Task Manager once input stops working.You can reply here with the details, or edit the issue. If you edit it, please also leave a short comment saying you've updated it, so we know you're done editing.
opencodejr commentedon Oct 30, 2026
We're closing this for now because we haven't heard back. To look into the TUI losing keyboard input (Esc/Ctrl+C) during long sessions, we need a few details we don't have yet: which terminal you use, your exact
opencode --version, the memory and CPU of the opencode process when input stops working, and the debug logs you offered.@arittner's comment points to Windows Terminal: they saw similar freezes there but none in WezTerm. If you can, try your setup in another terminal.
If this still happens on the latest 2.x release, reply here with those details and we can reopen it. Thanks for the thorough write-up!