Repository navigation
pkill -f command causes tool call hang in opencode TUI #25664
Description
Description
Summary
In opencode TUI, sending Execute：pkill -f vim 2>/dev/null; echo "killed" causes the bash tool call to hang until timeout. Replacing -f with -x or omitting the flag makes the command finish quickly. The issue occurs regardless of whether any vim process is running.
Steps to Reproduce
- Open opencode TUI.
- Send the message:
Execute：pkill -f vim 2>/dev/null; echo "killed" - Observe that the tool call hangs and does not complete until timeout.
- Repeat the test with:
Execute：pkill -x vim 2>/dev/null; echo "killed"Execute：pkill vim 2>/dev/null; echo "killed"
These complete immediately.
Actual Result
- With
pkill -f, the bash tool call stalls and eventually times out. - The behavior is identical whether a vim process exists or not.
Expected Result
All three variations should finish quickly, returning the output killed , without hanging.
CLI Test (for comparison)
Testing with opencode run shows different behavior:
$ opencode run 'Execute：pkill -f vim 2>/dev/null; echo "killed"'
> build · deepseek-v4-pro
[1] 25889 terminated opencode run 'Execute：pkill -f vim 2>/dev/null; echo "killed"'
The CLI command terminates itself, while the TUI hangs.
With -x or no flag:
$ opencode run 'Execute：pkill -x vim 2>/dev/null; echo "killed"'
> build · deepseek-v4-pro
$ pkill -x vim 2>/dev/null; echo "killed"
killed
killed
Works correctly.
Additional Information
- The issue is specific to the
-f(full argument list matching) flag ofpkill. - The hang occurs in TUI mode only; CLI via
opencode runbehaves differently (process terminated rather than hang). - Environment: opencode TUI (1.14.33), zsh as shell.
Possible Root Cause
pkill -f may be matching the opencode process itself or its child processes in the TUI context, leading to a deadlock or wait condition. The CLI test shows self‑termination, suggesting the TUI session handles process termination differently.
Plugins
none except default plugins
OpenCode version
1.14.33
Operating System
Ubuntu 24.04.4 LTS
Terminal
gnome-terminal
Activity
github-actions commentedon May 4, 2026
This issue might be a duplicate of existing issues. Please check:
In your case,
pkill -flikely matches the opencode process itself (as you noted in your root cause analysis), killing or signaling it in a way that leaves the stdio pipes in a broken state, causing the same hang pattern.Levosilimo commentedon Jul 3, 2026
Opened a fix for this in #35245 against
dev.The hang is one path: V1 waited on Node's
closeevent, which never fires when grandchildren inherit stdio. V2 (the core bash tool) wraps the read loop inEffect.scopedand bounds it withEffect.timeoutOrElse. V1 still had the V0 raceAll/handle.kill shape.This PR mirrors V2 in V1. The spawner's
acquireReleasefinalizer sends SIGTERM on scope cleanup. WhenEffect.timeoutOrElsecancels, theDeferred.awaitis interrupted cleanly. Pipes free, error propagates, bug-shape can't occur.I also created a companion plugin at https://github.com/Levosilimo/opencode-shell-hang-guard that rewrites
pkill -fto a basename-guarded variant. Useful until this PR ships, optional afterward.bun test test/tool/shell.test.tsfrompackages/opencode: 25 pass, 0 fail.AbdelftahZowail commentedon Aug 9, 2026
just fucking fix it already
aaronrancsik commentedon Sep 15, 2026
this is super annoying
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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
pizzav-xyz commentedon Oct 14, 2026
fucking fix it