Concurrent subagent dispatch: parent's permission state does not propagate to parallel subagents

Summary

When a parent dispatches 2+ subagents in parallel, the subagents behave asymmetrically even when given identical permission surfaces. One may succeed while another re-prompts or fails, or they fail with different error text. A single subagent dispatched serially with the same permission surface works correctly.

This is the umbrella bug — likely F6, F7, and F9 are all symptoms of this deeper parent→child permission-state handoff gap.

Setup

• Parent session with a complete permission surface declared in settings.json + settings.local.json
• Parent dispatches 2+ subagents simultaneously (via multiple Agent tool calls in a single message)
• Each subagent is given an identical prompt + identical permission requirements

Expected

All subagents see the same permission state and behave identically.

Actual

Subagents get different permission snapshots depending on dispatch timing. Observed in our wave-2 stress test: 5 concurrent agents, all with identical perm surfaces, all 5 failed with per-agent denials — but a single serial dispatch of the same task succeeded.

Reproducer

https://github.com/Regevba/FitTracker2/tree/main/docs/superpowers/plans/f6-f9-reproducer § F8

Why we think this is a runtime bug

No consumer-side config controls the order in which the runtime serializes permission state into a child-dispatch payload. The asymmetry across otherwise-identical concurrent children is only explainable by a race condition in the snapshot mechanism.

Impact

Parallel dispatch is effectively unusable. Our remediation program (30+ PRs) ran entirely serial after wave-2 aborted. This is the single biggest performance regression we have open.

Workaround

Serial dispatch.

Related

F6, F7, F9 likely specializations of this bug.