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
Windows: bash tool call doesn't return until spawned descendant processes exit; stdio redirection is not a workaround (1.18.30) #48369
On Windows, a bash tool call does not return when the command finishes if any process spawned during the call is still alive - even though the script itself exited and its output already streamed to the TUI. The turn stays wedged with no error until every descendant dies or the user aborts.
Key Windows detail: redirecting the child's stdout/stderr to files does NOT prevent this. Start-Process creates the child with handle inheritance enabled and no handle-list restriction, so the tool's stdout/stderr pipe write-handles leak to the child and its descendants regardless of redirection. There is no stdio-level workaround; the only reliable one we found is spawning long-lived processes out-of-tree via WMI (Win32_Process.Create - fresh handle table, outside the tool's process tree).
Measured with a controlled repro (no external tools involved):
script time
leftover child
delay before tool result returned
232 ms
pwsh -c "Start-Sleep 20", stdio inherited
~17 s
116 ms
same child, -RedirectStandardOutput <file>
~25 s
Real-world case: an npm-installed CLI that self-daemonizes (agent-browser v0.37.1 - first command spawns a daemon + headless Chrome with a 1h idle lifetime). Every cold-start bash call wedges the primary session; after the abort the daemon survives, so later calls look fine - which made it look like "screenshots hang", because screenshot tasks are the typical first command. Killing the daemon releases the call.
This matches #47350 (macOS, EOF-vs-exit mechanism) and the "primary wedges too" case explicitly excluded from #47546. #44601 anchors completion on process exit instead of pipe EOF; its approach would resolve this. Filing to (1) confirm it still reproduces on 1.18.30 and (2) record that on Windows redirection cannot mask the bug. #44601 has been open since Aug 24 - would appreciate a review.
Plugins
None relevant (a TUI cache-meter plugin is installed; unrelated to the bash tool).
OpenCode version
1.18.30
Steps to reproduce
Windows 11, opencode 1.18.30 (bash tool runs PowerShell).
Output appears immediately (~0.2 s), but the tool result returns only ~20 s later, when the hidden pwsh exits.
Same wedge with -RedirectStandardOutput <file> - redirection does not help on Windows.
Or reproduce with any self-daemonizing CLI: the first call wedges until abort; the surviving daemon makes subsequent calls fast until the next cold start.
If these cover the same underlying fix, it may make sense to consolidate. Otherwise, this report usefully adds the Windows-specific handle-inheritance detail (redirection cannot prevent pipe-handle leakage) that the earlier issues do not cover.
Activity
github-actions commentedon Sep 10, 2026
This issue might be a duplicate of existing issues. Please check:
If these cover the same underlying fix, it may make sense to consolidate. Otherwise, this report usefully adds the Windows-specific handle-inheritance detail (redirection cannot prevent pipe-handle leakage) that the earlier issues do not cover.
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊