Cross-session result contamination: concurrent dispatches deliver foreign partial results to the wrong parent session

[rz1989s]

Summary

Two subagent dispatches from session A returned partial results containing content from unrelated dispatches belonging to a different parallel session B. The children appear to have received (or their results were replaced/merged with) foreign task prompts/results. This is silent wrong-result delivery — the most dangerous failure mode for a fleet orchestrator, since a controller will act on plausible-looking output from the wrong task.

Environment

• @getpipher/armory-fleet 1.2.0, pi session A cwd ~/local-dev/getpipher/armory-fleet
• Session B running concurrently from the bug-bounty workstream (LayerZero TON hunt) + an armory-gateway review session
• Session A dispatches used readOnly: true (bypasses the foreground single-slot lock) while session B had write dispatches in flight (ROLE 3/ROLE 4 FLOW_1 R1 LayerZero TON, in_progress fleet todos)

Evidence

1. Dispatch A1 (task: "WEB RESEARCH … pi-extensions ecosystem … nicobailon/pi-interactive-shell …") returned:

   "The parallel session's extra claims verified: _oAppCheckPermissions gates LZ_RECEIVE_EXECUTE with assertChannelAddress(MdObj.obj) (:163-172) … Files modified before the cut: /Users/rector/local-dev/bug-bounty/hunts/immunefi-layerzero/rextor/_work/channel-R1-03-runtime-verify.md"

   LayerZero runtime verification — zero overlap with the research brief.

2. Dispatch A2 (task: "WEB RESEARCH … gemini-cli, claude-code, aider TUI patterns") returned:

   "Role 3 deliverable is complete and consolidated (120 lines, single verdict per NV, ordered facts F23-F32, experiments). The concatenated message also carried an earlier unaddressed dispatch — the armory-gateway Task 3 review."

   The child itself reports its input was a concatenation carrying a foreign dispatch.

3. A third dispatch (same batch, OpenClaw/OpenCode/Hermes brief) returned a correct on-brief report but with a foreign appendix: "armory-gateway Task 3 review (SPEC-1b D3, 3de8a60..19d76a5)".

4. The foreign content matches session B's live dispatch task texts (fleet-run todos, in_progress) and files written at the same minute (11:28).

Impact

• Controller receives plausible results for the WRONG task; on write dispatches this could mean commits/PRs attributed or verified against the wrong diff.
• Erodes trust in every parallel/dispatched result; forces manual provenance checks.

Suspected areas (hypotheses, unverified)

• Result routing/inbox keying that is not unique per session (shared inbox or runId collision across sessions).
• Prompt assembly concatenating a queued/foreign dispatch message into the child's input when the parent's dispatch overlaps another session's in-flight run (readOnly lock-bypass widens the window).
• Note session-level lock serializes within one session only; cross-session interleaving is unguarded.

Repro sketch

Two pi sessions in different cwds; session A fires a readOnly foreground dispatch while session B has an in-flight write dispatch; A's result (partial/turn-budget) contains B's task content. Not reliably reproducible yet — occurred 2/5 in one batch under live parallel load.

Ask

1. Audit the result-delivery path (inbox keying, runId minting, awaiting-parent resolution) for cross-session uniqueness.
2. Consider a provenance guard: child result carries the hash/prefix of its own task text; parent verifies match before surfacing, mismatch → hard error, never silent.

[rz1989s]

Third occurrence, different role: a task REVIEWER dispatched at ~12:3x (readOnly, cwd=worktree) cited a fabricated hunk ('src/index.ts — provider-registry export block, trimmed interceptors line') in its spec-compliance verdict. That file is not in the reviewed range (a770be9..e6ad1dc: vision patch + present tokens/glyphs). armory-gateway vocabulary again. Guards (ignore-foreign-content line in dispatch) worked on implementers; reviewers need the same line — added to the template going forward.

[rz1989s]

Fresh smoke evidence (P2 smoke, 2026-09-03, pi --no-extensions -e ./src/index.ts --no-session in the armory-fleet-p1 worktree) — two more bleed surfaces, both visible in one capture:

1. Foreign runs in the shared registry/panel: a concurrent session's runs (different dispatches, same fleet dir) appeared live in this session's /fleet panel — rows, totals ($0.07 of other-session spend) and live updates. Shared-dir by design, but the panel has no session-scope notion.
2. Global fleet TODOs in the orchestration entry tree: the read-only listFleetTodos projection rendered fleet-tracked TODOs from OTHER sessions/workstreams (LayerZero hunt rows, old P1 SDD task briefs) under this session's burst — no session/run filtering on the read side.

Not P2 regressions (both pre-date it), but they sharpen the #102 fix surface: the read-side projection needs at least a session/worktree scope filter alongside the dispatch guards. Evidence windows: fleet-p2-smoke2-u58xa0 (tmux, still up).