Skip to content

Bash tool never returns when a spawned command leaves a descendant holding its stdio pipes #50316

Open

Description

@LoikStyle

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:

  1. 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.

  2. 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.

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: 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

  1. Resolve the spawner's exit deferred on exit (close kept only as a fallback).
  2. 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.

OpenCode version

dev @ c101347

Operating System

Windows

Activity

  1. pauldupuyjr commented on Oct 13, 2026

    @pauldupuyjr

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions