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

Suspend (ctrl + z) pauses api calls for all opencode instances #3289

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

Originally created by @Eric162 on GitHub (Dec 3, 2025).

Description

I was running about 3 instances of opencode, i suspended 1 of them with ctrl+z and the other 2 stopped sending/receiving data.

When i fg they all resume where they left off.

OpenCode version

1.0.128

Steps to reproduce

  1. run opencode in in shell 1
  2. open new terminal tab (shell 2) in another folder
  3. run opencode in shell 2
  4. send message in shell 2
  5. switch to shell 1
  6. send message in shell-1
  7. press ctrl + z to suspend shell 1
  8. switch back to shell 2
  9. observe shell 2 responses hanging

Screenshot and/or share link

No response

Operating System

MacOS Sequoia Version 15.7.2 (24G325)

Terminal

WezTerm, Cursor

Originally created by @Eric162 on GitHub (Dec 3, 2025). ### Description I was running about 3 instances of opencode, i suspended 1 of them with ctrl+z and the other 2 stopped sending/receiving data. When i `fg` they all resume where they left off. ### OpenCode version 1.0.128 ### Steps to reproduce 1. run `opencode` in <folder-1> in shell 1 2. open new terminal tab (shell 2) in another folder <folder-2> 3. run `opencode` in shell 2 4. send message in shell 2 5. switch to shell 1 6. send message in shell-1 7. press ctrl + z to suspend shell 1 8. switch back to shell 2 9. observe shell 2 responses hanging ### Screenshot and/or share link _No response_ ### Operating System MacOS Sequoia Version 15.7.2 (24G325) ### Terminal WezTerm, Cursor
yindo added the opentuibug labels 2026-02-16 17:39:32 -05:00
yindo closed this issue 2026-02-16 17:39:32 -05:00
yindo commented 2026-02-16 17:39:32 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 3, 2025):

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

  • #3737: OpenTUI: ctrl-z background controls are broken - Related to ctrl-z functionality being masked by text box undo feature in OpenTUI
  • #584: ctrl+Z -> go to background - Feature request for ctrl-z to suspend opencode and return to shell

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

@github-actions[bot] commented on GitHub (Dec 3, 2025): This issue might be a duplicate of existing issues. Please check: - #3737: OpenTUI: ctrl-z background controls are broken - Related to ctrl-z functionality being masked by text box undo feature in OpenTUI - #584: ctrl+Z -> go to background - Feature request for ctrl-z to suspend opencode and return to shell Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:39:32 -05:00
Author
Owner
Copy Link
Copy Source

@Eric162 commented on GitHub (Dec 4, 2025):

opencode investigating found this:

Findings

  • ctrl+z is wired to the terminal_suspend command in the shipped config (packages/opencode/src/config/config.ts:447), so hitting ctrl+z inside OpenTUI always runs that command rather than letting the terminal driver handle job control.
  • The command handler (added in 6afdb5c0e5) lives in packages/opencode/src/cli/cmd/tui/app.tsx:366-377. It suspends the renderer and then calls process.kill(0, "SIGTSTP") to emulate “send the job to the background.” As the in-line comment notes, passing 0 targets the entire process group.
  • When you have multiple opencode TUIs that share the same process group (which is common whenever they’re launched from the same terminal session/multiplexer—WezTerm tabs, Cursor panes, tmux windows, or multiple opencode attach clients pointing at a single opencode spawn server), every process in that group receives the signal. That means the worker thread hosting the local Bun server plus any other TUIs in that group are also SIGTSTP’d, so their event loops stop processing API/network IO. They appear “hung” until a SIGCONT arrives, which matches the user’s observation that everything resumes right after they fg the instance they suspended.
  • The resume logic already hooks SIGCONT (app.tsx:371-373), so once the foreground job is continued, the renderer wakes up and the HTTP server continues accepting requests, letting all other instances drain their pending network work immediately.
    Why the issue occurs
    The new suspend implementation broadcasts SIGTSTP too broadly by signaling the whole process group (pid 0). In practice that group includes every OpenCode process launched from the same terminal session, so suspending one client inadvertently pauses the Bun worker/server that the other clients depend on, which freezes their request/response traffic until SIGCONT.
    Next steps
  1. Change the suspend handler to signal only the current job (e.g., process.kill(process.pid, "SIGTSTP") or explicitly target just the worker/TUI PIDs) instead of pid 0, or ensure each opencode invocation runs in its own process group (setpgid) before wiring ctrl+z.
  2. Add a regression test/manual QA note: run multiple TUIs simultaneously (including in tmux/WezTerm/Cursor panes) and verify suspending one instance no longer stalls the others.
    This should prevent the cascade pause described in issue #5043 while keeping the “ctrl+z to background” feature.
@Eric162 commented on GitHub (Dec 4, 2025): opencode investigating found this: > Findings > - ctrl+z is wired to the terminal_suspend command in the shipped config (packages/opencode/src/config/config.ts:447), so hitting ctrl+z inside OpenTUI always runs that command rather than letting the terminal driver handle job control. > - The command handler (added in 6afdb5c0e5) lives in packages/opencode/src/cli/cmd/tui/app.tsx:366-377. It suspends the renderer and then calls process.kill(0, "SIGTSTP") to emulate “send the job to the background.” As the in-line comment notes, passing 0 targets the entire process group. > - When you have multiple opencode TUIs that share the same process group (which is common whenever they’re launched from the same terminal session/multiplexer—WezTerm tabs, Cursor panes, tmux windows, or multiple opencode attach clients pointing at a single opencode spawn server), every process in that group receives the signal. That means the worker thread hosting the local Bun server plus any other TUIs in that group are also SIGTSTP’d, so their event loops stop processing API/network IO. They appear “hung” until a SIGCONT arrives, which matches the user’s observation that everything resumes right after they fg the instance they suspended. > - The resume logic already hooks SIGCONT (app.tsx:371-373), so once the foreground job is continued, the renderer wakes up and the HTTP server continues accepting requests, letting all other instances drain their pending network work immediately. > Why the issue occurs > The new suspend implementation broadcasts SIGTSTP too broadly by signaling the whole process group (pid 0). In practice that group includes every OpenCode process launched from the same terminal session, so suspending one client inadvertently pauses the Bun worker/server that the other clients depend on, which freezes their request/response traffic until SIGCONT. > Next steps > 1. Change the suspend handler to signal only the current job (e.g., process.kill(process.pid, "SIGTSTP") or explicitly target just the worker/TUI PIDs) instead of pid 0, or ensure each opencode invocation runs in its own process group (setpgid) before wiring ctrl+z. > 2. Add a regression test/manual QA note: run multiple TUIs simultaneously (including in tmux/WezTerm/Cursor panes) and verify suspending one instance no longer stalls the others. > This should prevent the cascade pause described in issue #5043 while keeping the “ctrl+z to background” feature.
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 bug opentui
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#3289
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?