Subagent permission request silently dropped → parent turn stuck busy forever; stop/interrupt are no-ops, survives client restart

Bug Description

When a subagent (Task tool) triggers a permission request (external_directory), the request can be dropped entirely — it never reaches the client UI, GET /permission, or GET /api/session/{id}/permission. The parent session's status stays busy forever waiting for a reply that nobody can give. The stop button does nothing, and POST /api/session/{id}/interrupt returns 204 but changes nothing, because by that point the runtime reports no active sessions at all (GET /api/session/active → {}). The result is an unkillable zombie turn that survives even a full client restart, and can only be cleared by editing the client's local database.

Steps to Reproduce

1. Run a turn in which a subagent works across directories such that it triggers an external_directory permission ask (observed with pattern=/Users/xhauch/.agents/skills/_mail-shared/*, action.action=ask). Parent agent = build, subagent mode = general.
2. Observe in the server log that the request is created (asking id=per_…) — but it is never surfaced to the connected client.
3. Client shows the turn as running/busy forever with zero output after that point.

Observed on v1.18.22 via the T3 Code desktop client (opencode serve --hostname=127.0.0.1).

Evidence (single incident, 2026-08-24, times UTC)

• 17:45:26 — parent streams normally, spawns subagent session ses_fcb1f726bffee4p0Ve67E57OAJ
• 17:45:48.956 — server logs both:
  • evaluated permission=external_directory pattern=/Users/xhauch/.agents/skills/_mail-shared/* action.permission=external_directory action.pattern=* action.action=ask
  • asking id=per_034e0e49c0019xUS5A6z5Rx0TC permission=external_directory patterns=["/Users/xhauch/.agents/skills/_mail-shared/*"]
• 17:45:48 → ∞ — no further events of any kind (no retries, no errors); client-side event stream for the thread also goes silent
• Later inspection (~18:00–19:55):
  • GET /permission → []
  • GET /api/session/{parent}/permission → {"data":[]}
  • GET /api/session/{subagent}/permission → {"data":[]}
  • GET /api/session/{parent}/question → {"data":[]}
  • GET /api/session/active → {"data":{}}
  • i.e. the pending ask is not visible through any API surface
• 17:44:52 (user pressed Stop earlier) and ~17:56 (direct API test) — POST /api/session/{id}/interrupt returned HTTP 204 both times, but the client-side turn remained running; consistent with /api/session/active already being empty, i.e. the runtime has lost track of the session it is still blocking on
• Full quit + relaunch of the desktop client did not settle the turn; the client re-attached and still showed the session as active
• The turn could only be cleared by editing the client store (state → interrupted) with the client fully stopped

Expected Behavior

Either:

1. The permission request should be delivered to the connected client (and be visible via GET /permission / per-session permission endpoints) so it can be answered, or
2. If delivery fails, the pending ask should time out / fail closed so the turn errors out instead of blocking forever, and
3. POST /api/session/{id}/interrupt must reliably cancel a turn blocked on an unanswered permission request.

Actual Behavior

The ask vanishes, the turn blocks indefinitely in busy, all cancel paths are no-ops against a session the runtime no longer tracks, and the state survives client restarts.

Environment

• OpenCode: v1.18.22 (installed via Homebrew, arm64)
• Client: T3 Code desktop app driving opencode serve --hostname=127.0.0.1
• OS: macOS 26.6.2 (arm64)
• Model path: provider opencode (Zen gateway), modelID x-preview-f-free
• Config note: permissions.external_directory was not set at the time (default ask); setting it to "allow" afterwards avoids triggering the bug but does not address the dropped-request/hang itself

Additional Context

• Possibly related (different trigger, same hang shape): #29952, #24342 — those involve sub-agent LLM-call failures; this one involves a sub-agent permission request being silently dropped.
• Happy to provide full sanitized logs (opencode.log excerpt around 17:45:48 UTC) if useful.