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

Activity

1. Eric162

   added

   bugSomething isn't workingSomething isn't working

   on Dec 4, 2025
2. github-actions

   added

   opentuiThis relates to changes in v1.0, now that opencode uses opentuiThis relates to changes in v1.0, now that opencode uses opentui

   on Dec 4, 2025
3. github-actions commented on Dec 4, 2025

   

   github-actionsBot

   on Dec 4, 2025 – with GitHub Actions

   Contributor

   More actions

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

   • OpenTUI: ctrl-z background controls are broken #3737: OpenTUI: ctrl-z background controls are broken - Related to ctrl-z functionality being masked by text box undo feature in OpenTUI
   • ctrl+Z -> go to background #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.
4. Eric162 commented on Dec 4, 2025

   

   Eric162

   on Dec 4, 2025

   ContributorAuthor

   More actions

   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 6afdb5c) 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 Suspend (ctrl + z) pauses api calls for all opencode instances #5043 while keeping the “ctrl+z to background” feature.
5. Eric162

   closed this as completedon Dec 8, 2025