Main & Sub-agents Randomly Freeze Indefinitely: Frontend Permanently Shows "thinking" with No Errors, While Actual LLM Inference Has Already Terminated Prematurely

[xsrtyq]

Description

When running workflows in OpenCode, we encounter an unpredictable, randomly occurring freeze bug that is reproducible in both main-agent and sub-agent scenarios:
A completely fixed, unmodified workflow that ran 100% successfully previously will start freezing randomly without any OpenCode version updates or environment configuration changes, with no identifiable trigger point;
The freeze occurs in two scenarios: ① main-agent directly calling basic tools (write/edit/question); ② main-agent invoking sub-agents via the Task tool;
When the main-agent freezes, the workflow can be forcibly advanced by manually clicking "Continue". When a sub-agent freezes, there is no corresponding interaction entry, and the entire session must be manually interrupted;
Freezes can occur during trivial, zero-complexity operations (e.g. asking fixed-option questions via the question tool, writing short text via the write tool), and are completely unrelated to task complexity or model inference difficulty;
When frozen, the frontend permanently displays "thinking", with no error messages, no tool call outputs, and no workflow termination signal. Through link troubleshooting, we have confirmed that the LLM-side inference has been fully completed with no subsequent outputs, but the frontend state is not synchronized and remains permanently in the executing state;
The bug is reproducible even in completely fresh, blank sessions, and even after fully restarting the OpenCode process before each test, completely ruling out the impact of session context pollution and process memory leaks.

Plugins

no plugin

OpenCode version

v1.14.24

Steps to reproduce

Configure any normally executable workflow, supporting two scenarios: ① A simple workflow where the main-agent directly calls basic tools (write/question); ② A multi-stage workflow where the Orchestrator main-agent invokes sub-agents via the task() tool;
Fully quit and restart the OpenCode process, open a completely fresh, blank session with no historical dialogue or context residue;
Run the fixed workflow start command, with no changes to the workflow logic or runtime environment throughout the test;
The freeze is triggered randomly: the frontend permanently shows "thinking" with no errors or tool call outputs, the workflow is permanently interrupted, and the LLM-side inference has already terminated prematurely at this point.
In sometimes it work good，if i have two same session，they will die in different place.
This issue has an extremely high reproduction rate on the DeepSeek V4 model: it randomly triggers freezes on both main and sub-agents even in zero-reasoning-complexity scenarios where the model’s native 1M long context window is fully sufficient, with the frontend permanently displaying "thinking" without any errors, while the actual inference and output on the DeepSeek V4 side have been completely terminated.

Screenshot and/or share link

Operating System

Windows11

Terminal

Windows terminal

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Critical bug: Opencode desktop get completly stuck #23481: Very similar symptoms — agents stuck with frontend permanently showing "thinking", no errors, requiring restart, also on Windows 11 + Windows Terminal
• Agent tool calls execute silently — UI frozen, no progress, exploration loop runs unchecked #18723: Similar UI frozen/"thinking" state with no progress, though that issue attributes it to a local tool-call loop rather than LLM inference completing without state sync
• Task Tool Timeouts & Early Termination in Multi-Agent Conductor Pattern #6792: Related multi-agent / Task tool early termination behavior

If your issue is the same root cause as any of the above, please consider adding your observations there rather than tracking separately. If you believe this is a distinct issue (e.g. specific to DeepSeek V4's response handling), please clarify what makes it different.

[xsrtyq]

I found that my issue is highly similar to #23481, though not identical. I also experience sluggish runtime performance.However, I can switch sessions freely while the agent is frozen. By enabling the AI thought display, I confirmed that although the interface keeps showing thinking, the actual LLM reasoning has long stopped.
Tool call freezes also occur frequently. When the AI attempts to write to a file, it gets stuck permanently at the "writing" status. If I interrupt manually at this moment, it prompts Tool execution aborted, and the entire session becomes broken and unusable. The whole process takes dozens of times longer than normal, resulting in a complete freeze.
In cases where reasoning stops silently, manual interruption will not crash the session, and I can resume and continue working with the current sub-agent normally.

[xsrtyq]

I am unsure whether this is caused by my local configuration. Please provide a solution as soon as possible if feasible. This issue severely affects daily usage experience. Thank you.

[lrq3000]

I also experience the same issue, it never happened before. It happens with ChatGPT-5.4-mini and ChatGPT-5.5 at a very high rate (almost all the time). The problem is that it also happens for me when there is no workflow, just a session. And the huge issue that compounds over is that the bug continues to happen when I close and reopen the desktop app, even if the process is killed in-between, on restart, somehow the GUI again gets frozen (cannot click on anything, it highlights stuff on hovering but I can action anything). Normally with a kill and fresh restart it should not freeze, so this means that on restart OpenCode decides to continue to run the sessions it considers unfinished, which is a big issue.

[lrq3000]

I was going to write that maybe it had to do with RAM overflow as I noticed that this happens almost systematically with ChatGPT-5.5 which somehow tries to run too heavy or too many parallel agents than my RAM can handle. And indeed after a while, the desktop app crashed with the error "Our Of Memory".

So I suspect that for all these cases, the common thread is a memory issue. I don't know what the agent is doing in the background but this does not appear to happen with ChatGPT-5.3-codex that I used for months without any issue. I also of course checked if it was a problem with any other app running on my system at the same time and that's not it.

[lrq3000]

So I confirm there is a memory leak somewhere, msedgewebview2.exe grows up to 5GB for no reason when switching from a dormant workspace to the workspace with the zombie session.

The zombie session continues to display with an orange animation, as if it was active (I'm not sure what this color code means), and it blocks most actions apart from switching to another workspace (if there is enough free RAM).