Serve mode: multi-tool-call turn silently drops one bash dispatch; session stuck "busy" forever (deterministic repro: 10/10 on v1.17.18 and v1.17.20)

[Smerked]

Description

In opencode serve mode, when the model emits two bash tool calls in a single response, one call executes and completes normally, while the other is never dispatched at all — no process is spawned, no filesystem effect occurs — yet its part state remains "status": "running" indefinitely. The session then reports {"type":"busy"} forever. POST /session/{id}/abort is the only recovery.

Key discriminator vs. similar reports: the dropped command was mkdir -p <path> and the directory was never created. This is not "tool completed but session failed to resume" (#22156) — the dispatch itself is lost. The sibling call from the same turn completes fine (17ms, normal exit).

Environment

• opencode v1.17.18 and v1.17.20 (opencode serve), both reproduce identically
• Ubuntu 24.04, x86_64
• Provider: custom OpenAI-compatible (@ai-sdk/openai-compatible) → llama.cpp llama-server, local 35B model, ~83 tok/s streaming
• Driven over the REST API: POST /session → POST /session/{id}/prompt_async → poll GET /session/status

Reproduction

Attached script (zombie-test.sh) runs N control sessions then N trigger sessions, sequentially, 120s limit each.

Control prompt (never triggers):

Call the bash tool exactly once with the command: echo control-1.
Do not call any other tools. Then stop and give a one-word answer.

Trigger prompt (triggers every time):

In one single response, call the bash tool TWICE (two separate tool
calls in the same response): first command: mkdir -p /tmp/zt-1/a
second command: echo done-1. Then stop and give a one-word answer.

Results

version | control (1 call/turn) | trigger (2 calls/turn) -- | -- | -- v1.17.18 | 10/10 completed | 10/10 stuck busy forever v1.17.20 | 10/10 completed | 10/10 stuck busy forever

Every stuck session shows the identical fingerprint: message log contains 2 tool parts, exactly 1 frozen at "running", and /tmp/zt-N/a was never created on disk.

Evidence from a stuck session (original field incident)

Message log tail — mkdir "running" forever, sibling completed in 17ms:

json

{ "type": "tool", "tool": "bash",
  "state": { "status": "running",
    "input": { "command": "mkdir -p .../toolchains/android-sdk/cmdline-tools && mkdir -p .../toolchains/android-sdk" },
    "time": { "start": 1783992687894 } } }
{ "type": "tool", "tool": "bash",
  "state": { "status": "completed",
    "input": { "command": "which java && java -version 2>&1" },
    "metadata": { "exit": 1 },
    "time": { "start": 1783992688311, "end": 1783992688328 } } }

Provider-side timeline (llama-server logs): the model turn that emitted both calls finished generating normally; the provider was never asked for another turn afterward. While the session sat "busy" there were zero established sockets to the serve process and no child processes (verified with ss and ps) — nothing was executing, nothing was in flight.

Notes

• Likely related (all report intermittent behavior with no deterministic repro): MCP tool completes successfully but session never resumes or finalizes in serve/web mode #22156, Empty bash tool arguments {} can still be submitted and interrupt the session #27871, Intermittent hang: session stays running forever until manual interrupt #14769, Tool and task execution can hang indefinitely with no timeout #20096, Sessions hang indefinitely when Task tool spawns subagents via REST API (opencode serve) #6573.
• Hypothesis for why this is deterministic here and intermittent elsewhere: the local provider streams at a very consistent rate (~83 tok/s, low jitter), so the two tool calls in a turn land at a highly repeatable interval — if the drop is a timing race in dispatch, a low-jitter emitter hits the vulnerable window every time, while cloud APIs (batched/jittery delivery) hit it occasionally.
• Reviewed v1.17.19 and v1.17.20 release notes before filing: no changes to tool dispatch, session state, or serve mode, consistent with identical reproduction on both tested versions.

Happy to run patches or additional diagnostics against this setup — the repro takes ~10 minutes and triggers 100% of the time.

Plugins

None

OpenCode version

v1.17.18 and v1.17.20 — reproduced identically on both

Steps to reproduce

1. Run opencode serve with any OpenAI-compatible provider (reproduced with llama.cpp llama-server, local 35B model; low-jitter local providers trigger it 100%)

2. Via REST: create a session (POST /session), then POST /session/{id}/prompt_async with:

   In one single response, call the bash tool TWICE (two separate tool
   calls in the same response): first command: mkdir -p /tmp/zt-1/a
   second command: echo done-1. Then stop and give a one-word answer.
   

3. Poll GET /session/status — the session stays busy forever; the message log shows one tool part frozen at "running"; /tmp/zt-1/a is never created on disk.

Attached script automates 10 control + 10 trigger sessions:
zombie-test.sh

Screenshot and/or share link

Placeholder@Placeholder-PC:~/TheProject/window-temp-android$ export $(sudo cat /etc/opencode-serve.env)
~/zombie-test.sh
=== CONTROL arm (1 call/turn) ===
[control 1] IDLE tools/running=1,0,ok dir=NA
[control 2] IDLE tools/running=1,0,ok dir=NA
[control 3] IDLE tools/running=1,0,ok dir=NA
[control 4] IDLE tools/running=1,0,ok dir=NA
[control 5] IDLE tools/running=1,0,ok dir=NA
[control 6] IDLE tools/running=1,0,ok dir=NA
[control 7] IDLE tools/running=1,0,ok dir=NA
[control 8] IDLE tools/running=1,0,ok dir=NA
[control 9] IDLE tools/running=1,0,ok dir=NA
[control 10] IDLE tools/running=1,0,ok dir=NA
=== TRIGGER arm (2 calls/turn) ===
[trigger 1] STUCK tools/running=2,1,ok dir=NO
[trigger 2] STUCK tools/running=2,1,ok dir=NO
[trigger 3] STUCK tools/running=2,1,ok dir=NO
[trigger 4] STUCK tools/running=2,1,ok dir=NO
[trigger 5] STUCK tools/running=2,1,ok dir=NO
[trigger 6] STUCK tools/running=2,1,ok dir=NO
[trigger 7] STUCK tools/running=2,1,ok dir=NO
[trigger 8] STUCK tools/running=2,1,ok dir=NO
[trigger 9] STUCK tools/running=2,1,ok dir=NO
[trigger 10] STUCK tools/running=2,1,ok dir=NO
=== SUMMARY ===
10 control IDLE
10 trigger STUCK
full log: /home/complex/zombie-test-results.txt

zombie-test-results.txt

Operating System

Ubuntu 24.04 (x86_64)

Terminal

N/A — headless serve mode, driven via REST API (no TUI involved)

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• GET /session/status can report a session busy for a short window (and occasionally indefinitely) after its prompt stream has already closed #35472: Server-side GET /session/status reporting busy indefinitely after prompt completion in serve mode — same symptom (session permanently stuck busy via REST API), same environment (headless opencode serve + polling /session/status). The root cause angle differs (status-map lag vs. dropped tool dispatch), but the observable failure and affected code paths overlap closely.
• Bug: deleteMessage (and other assertNotBusy-guarded APIs) permanently fail when a question tool part is stuck in state.status=running #27907: Session permanently busy when a tool part gets stuck in state.status: "running" — the exact fingerprint you describe (one tool part frozen at "running", session permanently busy) matches this issue's documented pattern, even if the trigger differs.

[Smerked]

Thanks — reviewed both carefully before filing; neither is a duplicate, but both are related and worth cross-linking:

vs #35472 — that issue describes the status map lagging behind a run that actually completed: the prompt resolves, the final assistant message is persisted and readable, and /session/status catches up late (usually <2s). Here the run never completes: the message log shows a tool part permanently frozen at "running", the command's process was never spawned (no filesystem effect — the mkdir target never appears), and the provider is never asked for another turn. Status is accurately reporting a genuinely wedged run, not lagging a finished one. One constructive overlap: #35472's "occasionally indefinitely" production tail has no repro — a silently dropped tool dispatch (this issue) would look exactly like unbounded status lag from an external client's viewpoint, so this may be the deterministic explanation for part of that tail.

vs #27907 — same fingerprint family (a tool part stuck at state.status: "running" → session permanently busy), so likely the closest relative. What this report adds: a deterministic trigger (a single model response containing two bash tool calls — one dispatches and completes, the other is silently dropped), physical evidence that the dropped call never executed, and a 10/10 reproduction script on both v1.17.18 and v1.17.20 (attached). If maintainers judge the underlying cause to be the same as #27907, happy to have this consolidated there — the repro script should transfer directly.

Happy to run diagnostics or candidate patches against this setup; the repro takes ~10 minutes and triggers 100% of the time.

[Smerked]

Root cause found — correcting this report. After filing, #36762 (headless permission ask hangs forever) was flagged as related, and a discriminating test against a wedged session confirms this issue is that bug's serve-mode variant, not a dropped tool dispatch.

Querying GET /permission on the serve instance returned eleven pending external_directory permission requests — exactly one per stuck session from the repro runs, each naming the "phantom" mkdir:

{
  "id": "per_f5e95a73f001Mg5oVHRsfdSH4k",
  "sessionID": "ses_0a16a5d68ffeyoALJY3GfgQsl8",
  "permission": "external_directory",
  "patterns": ["/tmp/zt-1/*"],
  "metadata": { "command": "mkdir -p /tmp/zt-1/a", "directories": ["/tmp/zt-1"] },
  "tool": { "messageID": "msg_f5e95a2b5001jDIb07q4qDA54F", "callID": "LhPtWdsyw4ApNfgl9ohclfXRGoHTRXaw" }
}

So the corrected account: the "never dispatched" call was gated on an external_directory ask that nothing in a headless serve deployment can answer. The tool part sits at state.status: "running" awaiting the reply, the turn never finishes, and the session is genuinely (not spuriously) busy forever. This retro-explains every observation in the report:

• The stuck command always targeted a path outside the session's project directory (/tmp/zt-N, and in the original field incidents /opt/... and a sibling directory of the project); the sibling calls that completed (echo, which java) touched no external path.
• 10/10 determinism: permission evaluation is policy, not timing — same path, same verdict every run. (Withdrawing my low-jitter/race hypothesis accordingly.)
• The provider is never asked for another turn: correct behavior for a turn that genuinely hasn't finished.
• My control/trigger test design had a confound — the trigger arm varied both call count and path externality. Call count was never the variable: the multi-call framing in the title is wrong.

What survives of this report: a deterministic, scriptable serve-mode reproduction of #36762's class (their repro paths are CLI opencode run; this is the REST/serve equivalent, where the hang presents as an eternally-busy session with a tool part frozen at running), plus two observability notes for anyone else hitting this: the pending ask is visible at GET /permission (it does NOT appear under /api/session/{id}/permission, which returned empty for the same session), and the session is recoverable via /permission/{requestID}/reply — not only abort.

Happy to have this closed as duplicate of / consolidated into #36762 — the attached zombie-test.sh transfers directly as a serve-mode repro for it (trigger = any command writing outside the project dir; the two-call shape is incidental).