anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Bug: opencode run and TUI exits hang on v0.15+ #2125

New Issue
Closed
opened 2026-02-16 17:34:17 -05:00 by yindo · 12 comments
yindo commented 2026-02-16 17:34:17 -05:00
Owner
Copy Link
Copy Source

Originally created by @jlrosende on GitHub (Oct 16, 2025).

Originally assigned to: @thdxr on GitHub.

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 with Ctrl+C.
  • In the interactive TUI on the same versions, issuing /exit or pressing Ctrl+C closes the interface visually, yet the terminal prompt never comes back—the process must still be terminated with Ctrl+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

  1. Install OpenCode 0.15.0 or later.
  2. Run opencode run "say hello" --print-logs inside a project directory.
  3. Wait for the response to finish streaming.
  4. 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

  1. Start the interactive TUI (opencode <path|project>).
  2. After the assistant finishes a task, enter /exit or press Ctrl+C to leave the session.
  3. The TUI clears and disappears, but the shell prompt does not return; pressing Ctrl+C is still required to regain control.

Expected Behavior

  • opencode run should terminate automatically once the assistant finishes processing the prompt.
  • /exit or Ctrl+C inside the TUI should gracefully shut down the session and immediately return the shell prompt.

Actual Behavior

  • opencode run stays 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-logs does not show any obvious error; logs end after the final session.prompt ... finish-step entry.
  • Downgrading to 0.14.7 is the only workaround identified so far.
Originally created by @jlrosende on GitHub (Oct 16, 2025). Originally assigned to: @thdxr on GitHub. ## 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 with `Ctrl+C`. - In the interactive TUI on the same versions, issuing `/exit` or pressing `Ctrl+C` closes the interface visually, yet the terminal prompt never comes back—the process must still be terminated with `Ctrl+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` 1. Install OpenCode 0.15.0 or later. 2. Run `opencode run "say hello" --print-logs` inside a project directory. 3. Wait for the response to finish streaming. 4. 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` 1. Start the interactive TUI (`opencode <path|project>`). 2. After the assistant finishes a task, enter `/exit` or press `Ctrl+C` to leave the session. 3. The TUI clears and disappears, but the shell prompt does not return; pressing `Ctrl+C` is still required to regain control. ## Expected Behavior - `opencode run` should terminate automatically once the assistant finishes processing the prompt. - `/exit` or `Ctrl+C` inside the TUI should gracefully shut down the session and immediately return the shell prompt. ## Actual Behavior - `opencode run` stays 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-logs` does not show any obvious error; logs end after the final `session.prompt ... finish-step` entry. - Downgrading to 0.14.7 is the only workaround identified so far.
yindo closed this issue 2026-02-16 17:34:17 -05:00
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Oct 16, 2025):

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

  • #1717: TUI exits but process hangs (no shell return) when opencode.json is present - Similar hanging behavior on TUI exit, requires Ctrl+C to regain shell prompt
  • #854: On exit - hangs in terminal - Reports hanging behavior after running requests and exiting
  • #1810: /exit hangs after new session - Specifically mentions /exit hanging after new session creation

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Oct 16, 2025): This issue might be a duplicate of existing issues. Please check: - #1717: TUI exits but process hangs (no shell return) when opencode.json is present - Similar hanging behavior on TUI exit, requires Ctrl+C to regain shell prompt - #854: On exit - hangs in terminal - Reports hanging behavior after running requests and exiting - #1810: /exit hangs after new session - Specifically mentions /exit hanging after new session creation Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 16, 2025):

Do you have an mcp server? Wonder what could be causing the hang

@rekram1-node commented on GitHub (Oct 16, 2025): Do you have an mcp server? Wonder what could be causing the hang
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@jlrosende commented on GitHub (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.

@jlrosende commented on GitHub (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.
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 16, 2025):

I think I saw a pr that might fix this, ill get back to u on that

@rekram1-node commented on GitHub (Oct 16, 2025): I think I saw a pr that might fix this, ill get back to u on that
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@veracioux commented on GitHub (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?

@veracioux commented on GitHub (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?
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@jlrosende commented on GitHub (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.

@jlrosende commented on GitHub (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.
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@iatsiuk commented on GitHub (Nov 6, 2025):

can confirm this issue is still present on the latest master branch (commit 67f3c934). 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 via state().track(), so graceful shutdown waits for it and has no timeout mechanism, causing the 50+ second hang.

@iatsiuk commented on GitHub (Nov 6, 2025): can confirm this issue is still present on the latest `master` branch (commit `67f3c934`). 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 via `state().track()`, so graceful shutdown waits for it and has no timeout mechanism, causing the 50+ second hang.
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 6, 2025):

@iatsiuk i can add a timeout to it, ill put a 30 second timeout hows that?

@rekram1-node commented on GitHub (Nov 6, 2025): @iatsiuk i can add a timeout to it, ill put a 30 second timeout hows that?
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@iatsiuk commented on GitHub (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.

@iatsiuk commented on GitHub (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: ```json { "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.
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (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

@rekram1-node commented on GitHub (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
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@spoj commented on GitHub (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.

@spoj commented on GitHub (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.
yindo commented 2026-02-16 17:34:17 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 11, 2025):

and u can reliably reproduce? does it happen with opencode run too?

@rekram1-node commented on GitHub (Dec 11, 2025): and u can reliably reproduce? does it happen with opencode run too?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2125
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?