Repository navigation
Bash tool never returns when a spawned command leaves a descendant holding its stdio pipes #50316
Description
Description
The bash tool never returns for a command that starts a background service. The command's own process exits, the service comes up, and the tool call waits forever. Two independent waits keep it open:
-
packages/core/src/cross-spawn-spawner.tsresolves the exit deferred onclose. Node only emitscloseafter the child's stdio streams have closed, and a detached descendant that inherits stdout/stderr keeps those pipes open — so for a server,closenever fires.@effect/platform-noderesolves the same signal onexit. -
packages/core/src/process.tsreadshandle.all/handle.stdout/handle.stderrto end of stream. Those reads wait on the same held-open pipes, so fixing (1) alone does not unblockrun— verified by reverting either half on its own: the hang comes back either way.
Steps to reproduce
node -e 'const {spawn}=require("node:child_process");const c=spawn(process.execPath,["-e","setTimeout(()=>{},60000)"],{stdio:["ignore","inherit","inherit"],detached:true});c.unref();console.log("done")'The command prints done and exits, but the tool call does not return.
Measurements
- Same command shape:
exitfires at ~125 ms,closeat ~3160 ms when the grandchild lives 3 s. When the descendant is a server,closenever fires at all. That gap is the hang. - Stopping the output read at exit does not truncate output: outstanding bytes at
exitmeasured 0 for payloads up to 64 MiB (a child cannot exit before it has finished writing, because it blocks on the pipe buffer until the reader drains it). - A regression test that spawns a detached grandchild and expects the run to settle with its output intact fails (times out) if either half above is reverted on its own.
Suggested fix
- Resolve the spawner's exit deferred on
exit(closekept only as a fallback). - Stop reading output at exit, e.g.
handle.all.pipe(Stream.interruptWhen(handle.exitCode)), at all four collection sites inprocess.ts:combineOutput,stdout,stderr, andrunStream.
Related
Open PRs in this area: #42275 and #42756 (spawner only), #44601 (both files), #45407, #49857. Per the measurements above, the spawner-only ones are not sufficient on their own.
OpenCode version
dev @ c101347
Operating System
Windows
Activity
pauldupuyjr commentedon Oct 13, 2026
Confirmed via a different trigger route than the repro, plus a Windows workaround that holds while the fix is pending.
We run opencode as the agent runtime inside a desktop automation app, and agents execute long test suites through the bash tool on Windows with a PowerShell 5.1 shell. The launch shape is Start-Process with -RedirectStandardOutput, -RedirectStandardError, and -WindowStyle Hidden: requesting redirection forces .NET's UseShellExecute=false path, which duplicates every inheritable handle into the child, including the shell's own stdout and stderr pipe write ends. The net effect matches the stdio:"inherit" repro exactly: the launcher finishes in seconds, the shell exits, and the tool call sits unresolved. Two agent runs were lost to this before we traced it here: the tool call sat unresolved while the detached suite kept running underneath, and each stalled run had to be interrupted from outside about ten minutes in.
Workaround that holds for us: spawn the detached child through WMI instead, for example ([wmiClass]"Win32_Process").Create('cmd /c > out.log 2>&1'), then poll out.log for progress. The WMI service creates the process rather than the calling shell, so the child inherits no handles, and the tool call returns immediately.
Your two-waits analysis matches the v1.18.32-era code line we run, including the process.ts collection half. Happy to test a fix PR against this setup if that is useful.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up and measurements!
The commit you tested,
dev @ c101347, is on the old v1 line (1.18.x). Thev2branch replaceddevon 2026-10-10. v1 only gets fixes for critical bugs (data loss, security problems, crashes with no workaround), so this is unlikely to be fixed there. Until then you can avoid the hang by redirecting or closing the background service's stdio, e.g.cmd > server.log 2>&1 &.In v2 (
@opencode/cli, 2.x) this case is already handled. Inpackages/util/src/cross-spawn-spawner.tsthe spawner waits forexit, then givescloseup to 1 second. If a detached descendant is still holding the pipes after that, it ends the output streams and discards whatever the descendant writes later, so the call returns instead of hanging. Both parts you describe are covered: theexit/closewait and the output reads inprocess.ts. We'd encourage upgrading to v2.If you can reproduce the hang on a current v2 release (
opencode --versionshowing 2.x), or you think this is critical for v1, please reply here with the version and the command, and we'll take another look. The related PRs you listed (#42275, #42756, #44601, #45407, #49857) target the v1 code paths.opencodejr commentedon Oct 29, 2026
Closing this as not planned. The report is about the v1 line (
dev @ c101347, 1.18.x), which only gets fixes for critical bugs. In v2 (@opencode/cli, 2.x) the spawner already handles this case: after the process exits, it waits up to 1 second forcloseand then stops reading output that a detached descendant is still holding open, so the call returns. On v1 you can avoid the hang by redirecting the background service's output, e.g.cmd > server.log 2>&1 &.If you still see the bash tool hang on a current v2 release, please open a new issue with the
opencode --versionoutput and the command. Thanks again for the thorough write-up!