Repository navigation
agent: agent freezes for ~10 minutes after any response interruption #56941
Description
Description
Summary
When an agent response is interrupted (by Ctrl+C, session compaction, network hiccup, etc.), the agent stops responding for approximately 10 minutes. Restarting OpenCode, deleting messages, or resending messages does not recover from this state.
Environment
- opencode version: 2.0.32
- OS: Windows 11 Pro (build 22631, 22H2)
- Terminal: xterm-256color (likely via Windows Terminal or similar)
- Shell: cmd.exe
- Install/channel: latest
- Active plugins: None found in config
Reproduction
- Start an OpenCode chat session
- Have the agent generate a response (any length)
- Interrupt the response (Ctrl+C, wait for session compaction, network interruption, etc.)
- Try to continue the conversation - send a new message or retry
Expected Behavior
The agent should recover gracefully and respond to new messages immediately after an interruption.
Actual Behavior
The agent shows "Working" text but never resolves - no output, no error, no thinking indicator. This frozen state persists for ~10 minutes. Restarting OpenCode, deleting the interrupted message, or resending does not break out of the frozen state.
Additional Context
- Frequency: Happens after any interruption type (not specific to session compaction)
- No error messages or logs visible in the UI
- The "Working" indicator appears but never transitions to a response
- Workaround: Wait ~10 minutes for it to recover on its own
- Config: Standard opencode.jsonc with shell permissions for npm/node/git
- This makes the tool unreliable for interactive use since any accidental interruption causes a long downtime
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot
No response
Operating System
No response
Terminal
No response
Activity
opencode-agent commentedon Oct 19, 2026
Thanks for the report! To work out where the ~10 minute hang comes from, could you add:
opencode/..., Anthropic, OpenAI, a local model).You can reply here with the details or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know when you're done.
These existing issues look related, ordered from most to least likely. Please check whether one of them already covers your problem:
Alice0318-skyline commentedon Oct 19, 2026
Provider/Model: LongCat 2.5 Preview Free & MiMo-V2.6-Flash Free (both free-tier models, likely via an API gateway). May apply to others but confirmed with both.
Logs: Can't share raw logs (contain sensitive data), but the pattern is consistent: interruption → "Working" indicator → ~10 min freeze → recovers on its own.
New session test: A brand-new session in the same project responds immediately. Only the interrupted session is frozen.
Trigger: Ctrl+C / Esc alone triggers it — no compaction or network drop needed. Simple interruption of any response causes the ~10 min hang.
opencode-agent commentedon Oct 19, 2026
Thanks for the details! I tried this on 2.0.32 with a simulated model: I interrupted a streaming reply with Esc and then sent a new message in the same session. The new reply came back immediately both times, with no stuck "Working" state. So OpenCode's own interrupt-and-continue path looks fine.
You also said a new session works right away, restarting doesn't help, and it clears after about 10 minutes, and you've seen it with both Zen free models (MiMo-V2.6-Flash Free and LongCat 2.5 Preview Free). Together that suggests the provider side, for example the aborted request still holding that conversation until it times out. I can't test that here without a real account on those models, so a maintainer with access will need to look into it. Related reports with per-conversation provider problems: #53120 and #54538.
If you can, it would help to know whether the same thing happens with a non-free or non-Zen model (e.g. your own API key for a provider).