You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bash tool never returns when a spawned command leaves a descendant holding its stdio pipes #50316
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.ts resolves the exit deferred on close. Node only emits close after the child's stdio streams have closed, and a detached descendant that inherits stdout/stderr keeps those pipes open — so for a server, close never fires. @effect/platform-node resolves the same signal on exit.
packages/core/src/process.ts reads handle.all / handle.stdout / handle.stderr to end of stream. Those reads wait on the same held-open pipes, so fixing (1) alone does not unblock run — verified by reverting either half on its own: the hang comes back either way.
The command prints done and exits, but the tool call does not return.
Measurements
Same command shape: exit fires at ~125 ms, close at ~3160 ms when the grandchild lives 3 s. When the descendant is a server, close never fires at all. That gap is the hang.
Stopping the output read at exit does not truncate output: outstanding bytes at exit measured 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 (close kept only as a fallback).
Stop reading output at exit, e.g. handle.all.pipe(Stream.interruptWhen(handle.exitCode)), at all four collection sites in process.ts: combineOutput, stdout, stderr, and runStream.
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.
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.
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.