Repository navigation
Bug: opencode run and TUI exits hang on v0.15+ #3213
Description
Summary
- On OpenCode 0.15.0 and later, the CLI launched with
opencode run <prompt>never returns control to the shell; it finishes streaming output but the process keeps running until interrupted withCtrl+C. - In the interactive TUI on the same versions, issuing
/exitor pressingCtrl+Ccloses the interface visually, yet the terminal prompt never comes back—the process must still be terminated withCtrl+C. - Downgrading to 0.14.7 immediately restores the correct behaviour, confirming this is a regression introduced in the 0.15.0 line.
Steps to Reproduce
Scenario A – opencode run
- Install OpenCode 0.15.0 or later.
- Run
opencode run "say hello" --print-logsinside a project directory. - Wait for the response to finish streaming.
- Observe that the command never exits back to the shell; the cursor sits on a blank line until you press
Ctrl+C.
Scenario B – TUI /exit
- Start the interactive TUI (
opencode <path|project>). - After the assistant finishes a task, enter
/exitor pressCtrl+Cto leave the session. - The TUI clears and disappears, but the shell prompt does not return; pressing
Ctrl+Cis still required to regain control.
Expected Behavior
opencode runshould terminate automatically once the assistant finishes processing the prompt./exitorCtrl+Cinside the TUI should gracefully shut down the session and immediately return the shell prompt.
Actual Behavior
opencode runstays attached to the session indefinitely, leaving the terminal blocked until interrupted.- The TUI window closes, yet the underlying process continues running and the shell prompt never reappears on its own.
Environment
- OpenCode: 0.15.0, 0.15.1, 0.15.2 (works as expected on 0.14.7)
- Platforms tested:
- Windows 11 (WSL2 Ubuntu 24.04)
- Fedora 42 (bare metal)
- Shells/Terminals: Windows Terminal (WSL), GNOME Terminal and Ghostty on Fedora (bash and zsh)
Additional Notes
- Clearing caches, reinstalling, or switching providers/models does not resolve the hang.
--print-logsdoes not show any obvious error; logs end after the finalsession.prompt ... finish-stepentry.- Downgrading to 0.14.7 is the only workaround identified so far.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Oct 16, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
rekram1-node commentedon Oct 16, 2025
Do you have an mcp server? Wonder what could be causing the hang
jlrosende commentedon Oct 16, 2025
I'm currently using GitHub's MCP (the remote version) for development. I've tried disabling them using the enabled parameter, and the problem persists. I've also commented on the configuration, and the problem persists.
rekram1-node commentedon Oct 16, 2025
I think I saw a pr that might fix this, ill get back to u on that
veracioux commentedon Oct 17, 2025
@rekram1-node I couldn't reproduce this without MCP servers. I have also observed no difference between 0.14.7 and latest versions. One thing I did observe is that opencode hangs for a few seconds before exiting if session title generation is pending. I've addressed this in #3083.
@jlrosende Is it possible that you didn't wait long enough before pressing Ctrl+C? Also, it might be that you don't have 100% controlled conditions - you might have project-local config files or something that is configuring MCP servers as enabled. Are you able to reproduce using
XDG_CONFIG_DIR=nonexistent opencode run <prompt>in a Linux environment?jlrosende commentedon Oct 18, 2025
I've been able to run more tests on the client in newer versions, and I've even managed to create a remote MCP server, which I've caused to experience various network errors. The certificate validation and DNS resolution errors are the errors that caused the process to freeze and not release when closing the TUI or terminating the process in command mode.
iatsiuk commentedon Nov 6, 2025
can confirm this issue is still present on the latest
masterbranch (commit67f3c934). process hangs for 50+ seconds after LLM generation completes before finally exiting.ensureTitle()function makes LLM request to auto-generate session titles. this request hangs indefinitely when the LLM provider doesn't respond, is registered viastate().track(), so graceful shutdown waits for it and has no timeout mechanism, causing the 50+ second hang.rekram1-node commentedon Nov 6, 2025
@iatsiuk i can add a timeout to it, ill put a 30 second timeout hows that?
iatsiuk commentedon Nov 6, 2025
thanks for agreeing to add the timeout!
would it be possible to make the timeout configurable rather than hardcoding 30 seconds? different users might need different values depending on their setup, for example local models (Ollama, LocalAI) might legitimately need 60+ seconds, some fast cloud providers (Anthropic, OpenAI) work fine with 10 seconds or reasoning models (DeepSeek, o1) might need 30-45 seconds
proposed config format:
{ "timeouts": { "titleGeneration": 30000 } }with fallback to 30 seconds as default if not specified. this would allow users experiencing issues with slower providers to adjust it without code changes.
rekram1-node commentedon Nov 6, 2025
thats a good point, we do have model level timeouts that are respected currently, and bun defaults to 5 min if nothing is being sent back and forth
spoj commentedon Dec 11, 2025
I'm experiencing this exit hang issue on Windows (native, not WSL). When I press Ctrl+C to exit, the TUI clears but the process doesn't terminate - I have to use Task Manager to kill it.
rekram1-node commentedon Dec 11, 2025
and u can reliably reproduce? does it happen with opencode run too?
fix: detect opencode completion via JSON event stream, not heuristics