Repository navigation
unstable internet leaves opencode in stuck state #40625
Description
Description
I have unstable internet, which drops packets every few hours. This causes opencode to get stuck in a state where it doesn't error out. It just seems to stall. Permanently saying "Esc to interrupt" and nothing happening.
Ive tried to make a watchdog script, but that stalls when opencode stalls.
Some info from gemini:
When a network connection drops mid-stream (specifically a silent TCP drop or packet loss without an explicit FIN or RST packet from the server), OpenCode hangs indefinitely in the streaming/busy state. The TUI remains stuck displaying "ESC to interrupt", no incoming tokens are rendered, and no request timeout is triggered. Furthermore, the process hangs or blocks the Node/Bun event loop during this state, preventing internal JavaScript plugin hooks or external IPC/events from recovering or receiving command signals.
Plugins
No response
OpenCode version
1.18.11
Steps to reproduce
Start an interactive session in opencode.
Submit a prompt that generates a multi-second response.
Mid-stream, simulate a silent network drop (e.g., disable Wi-Fi, pull Ethernet cable).
Observe OpenCode's behavior.
Screenshot and/or share link
No response
Operating System
linux
Terminal
kde teminal
Activity
github-actions commentedon Aug 5, 2026
This issue might be a duplicate of existing issues. Please check:
Gibbz commentedon Aug 6, 2026
ive managed to get a watchdog script working around the issue for now :)
VirtualZer0 commentedon Aug 12, 2026
I run into this problem all the time, and it’s just unbearable. I literally can’t work in orchestration mode because if one subagent freezes, the main agent just ends up waiting forever, and I can’t even force a specific subagent to terminate.
I really hope this bug gets fixed and isn’t just closed because “ummm, erm, there hasn’t been any activity here for 30 days, and even though the problem exists, we’re not going to fix it,” because in the current situation, OpenCode is simply unusable for me. It’s very frustrating to start a long-running task, then come back 8 hours later and see that there’s been no progress at all because the very first agent froze and simply stopped working.
EchoCode101 commentedon Aug 16, 2026
Environment
Background
I'm experiencing a very similar form of the "stuck/busy" behavior described here.
In my case, OpenCode does not necessarily appear completely frozen. It sometimes stops printing thoughts or text for an extended period, while the application itself remains open.
Interestingly, clicking around the UI a few times or opening Settings sometimes causes it to become responsive again. I've also observed cases where a large amount of output suddenly appears in a burst after the stall, which makes it look like OpenCode was continuing to process in the background and the UI/output was simply not being updated.
What I Found
I noticed that Windows Task Manager had automatically enabled Efficiency mode for the OpenCode process.
This appears to put the process under Windows' resource-management policies, potentially reducing its CPU priority/resource allocation when Windows considers it a background or less-important workload.
The important part is that Windows seems to re-enable this behavior after restarting OpenCode or rebooting the system.
Workaround
As a temporary workaround, disabling Efficiency mode for the OpenCode process in Task Manager made a noticeable difference.
I also increased the process priority, which made OpenCode significantly more responsive and reduced the frequency/severity of the apparent hangs.
For a more persistent solution, I'm using Process Lasso Pro to apply a persistent process rule to OpenCode. This allows the process configuration to be reapplied automatically instead of manually changing it in Task Manager after every restart.
In short:
This is obviously not a confirmed root-cause fix, and I wouldn't claim that Windows Efficiency mode is responsible for the original issue. However, in my case it made the application substantially more responsive and the stalls became negligible.
The database/storage cleanup mentioned above also seems like a useful troubleshooting step, particularly given the reports involving large amounts of OpenCode data.
Additional Observation
The combination of:
could potentially explain why the application sometimes appears "stuck" even though work is still happening in the background.
So if you're seeing the same behavior on Windows, I'd suggest checking Task Manager → Efficiency mode before assuming that OpenCode itself has completely deadlocked.
Screenshots:
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊