Headless doom_loop permission leaves completed parallel bash calls running

[naiba]

Description

In OpenCode 1.18.3, a headless subagent can deadlock when repeated parallel tool calls trigger a doom_loop permission request.

Observed sequence:

1. A subagent submitted three identical go test -race -shuffle=on -count=1 ./... Bash calls in one parallel batch.
2. All three commands finished successfully and produced output with exit code 0.
3. OpenCode created a pending permission request with permission: "doom_loop" and patterns: ["bash"].
4. The session processor waited at the permission Deferred. The successful tool results were not settled, all three Bash parts remained running, and the synchronous parent task waited indefinitely.
5. Replying once to that permission request immediately allowed all three parts to become completed with exit code 0 and the subagent resumed.

Expected behavior:

• A permission request from a headless/subagent session should be routed to a responder or explicitly rejected/timed out instead of waiting forever.
• A permission wait should not prevent already-finished parallel tool invocations from settling their results.

This overlaps with #22167 and #13715, but the additional symptom here is that already-successful parallel tool calls remain running because their results are not consumed while the processor is waiting on Permission.ask. PR #32301 may improve nested permission routing, but it does not appear to cover this result-settlement behavior.

Plugins

oh-my-openagent (subagent orchestration)

OpenCode version

1.18.3

Steps to reproduce

1. Run OpenCode in a headless/server context with the default doom_loop: ask behavior and no permission responder attached to the child session.
2. Start a synchronous subagent task.
3. In one tool turn, have the subagent issue the same Bash command three times in parallel. The observed command was go test -race -shuffle=on -count=1 ./....
4. Wait for the doom_loop permission request.
5. Observe that the commands have produced successful output, but their tool parts remain running and the parent task does not return.
6. Reply once to the pending permission request. The completed results settle immediately and the child session continues.

Screenshot and/or share link

No public share link. The state was verified through the local server permission endpoint, session event log, and tool-part records.

Operating System

Ubuntu 24.04.4 LTS, Linux aarch64

Terminal

Headless OpenCode server/API

[github-actions]

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

• Agent hangs indefinitely when using opencode serve + opencode attach if any permission is set to "ask" #16367: Agent hangs indefinitely with opencode serve when doom_loop permission is set to ask in headless mode — same root cause of permission waiting without a responder
• Permission asks from nested subagent sessions silently hang #13715: Permission asks from nested subagent sessions silently hang — directly related to subagent permission routing

The additional symptom you've identified (already-completed parallel tool calls remaining running while the processor waits on Permission.ask) adds a new angle beyond what those issues cover, so if you feel this is distinct enough, feel free to leave it open for maintainer review.