Subagent replies delivered to the wrong session when multiple sessions run agents concurrently (Windows)
Environment
- Claude Code 2.1.205, Windows 11 Home (build 10.0.26200), native (no WSL)
- Multiple concurrent sessions on the same machine, in different project directories, each spawning subagents via the Agent tool
- Pinned agent definitions in
~/.claude/agents/*.md(haiku/sonnet/opus tiers)
Summary
With two or more sessions running subagents at the same time, subagent replies have crossed between sessions in both directions, and one subagent's reply arrived empty despite a completed run. Three incidents over two days:
- 2026-07-13 ~21:00 local — Session A (game-simulator project, session id
a63ca347-caf9-4b84-bc99-3cd44340b48b) received task content that clearly belonged to a different session (documentation-tooling work, no relation to the project). Treated as untrusted and discarded. - 2026-07-14 — the reverse direction: Session B (documentation work in a different project dir) received a subagent reply that unmistakably described Session A's work. The two sessions were active concurrently.
- 2026-07-14 — a search subagent in Session A ran to completion (33 tool uses, ~64k tokens by the task notification) but its returned result was empty — no findings text at all. The work had visibly happened; the reply content was lost.
Impact
- Correctness: the orchestrating session can act on another session's data, or on nothing.
- Privacy/security: content crosses project boundaries silently. On a machine with sessions for different clients/projects, one project's code details leak into another session's context. It is also a prompt-injection surface: a "subagent reply" is implicitly trusted by orchestration patterns, and here it can contain arbitrary other-session content.
Suspected area (hypothesis, not verified)
The symptoms fit a wrong read on the task-result path rather than model behavior: results appear associated with per-session task directories under %LOCALAPPDATA%\Temp\claude\<project-slug>\<session-id>\tasks\. A collision or wrong-session resolution when several sessions complete tasks near-simultaneously would produce exactly this: swapped replies in both directions plus the occasional empty read. All three incidents happened only while ≥2 sessions were running subagents concurrently; single-session operation has never shown it.
Reproduction
Not deterministic. Setup that has produced it twice in two days:
- Open two Claude Code sessions in different project directories on the same Windows machine.
- Have both orchestrate work through subagents (Agent tool), overlapping in time.
- Occasionally a subagent reply in one session contains the other session's content, or arrives empty.
Notes
- Both affected sessions were the user's own; no network/multi-user component is suspected.
- The zero-byte
.outputfiles in the tasks directory appear normal for in-band Agent results (background Bash tasks write non-empty ones), so the empty-reply incident is listed as a symptom, not evidence of mechanism.
3 Comments
The task-result path collision you're describing is a real correctness hazard. The scenario where two sessions complete subagent work near-simultaneously and reads land on the wrong session's output file is exactly the kind of non-deterministic failure that's hard to reproduce reliably but damaging when it hits -- especially for the prompt-injection risk you flagged. Subagent results are implicitly trusted by the orchestrating session, so wrong-session content arriving in a trusted slot is a meaningful attack surface even on a single-user machine with different client projects.
The temp-directory path structure you identified (
%LOCALAPPDATA%\Temp\claude\<project-slug>\<session-id>\tasks\) suggests the disambiguation key is the session-id path component. If sessions resolve task output by something coarser than that (project slug, timestamp window), concurrent completions will collide. A minimal diagnostic: does the crossing happen less when the two sessions are in the same project directory vs. different directories? That would narrow whether slug-based or global-temp disambiguation is the failure point.On the zero-byte reply incident: if the session-id path is correct but the file write and the read race at task completion time (write not flushed when the orchestrator reads), a zero-byte output is consistent with a TOCTOU read rather than the same cross-session collision. Worth separating from the cross-session case since the fix surfaces are different.
Both failure modes share the same root: no authoritative handshake between the subagent write and the parent read, so the parent cannot distinguish "correct result" from "someone else's result" from "partial write." A spawn-time receipt (subagent writes its own session-id + parent session-id into a correlation file before doing any work) would make the handshake explicit and detectable.
(Disclosure: I'm Kyle Carriedo, building Claudeverse -- claudeverse.ai -- a tool that coordinates multiple Claude Code sessions externally. Cross-session state isolation is the hardest part of that problem from the outside too.)
Hit this too on parallel runs. The failure mode where a subagent reply lands in the wrong session is hard to catch after the fact if the log is only in memory. Been recording every tool call to an external append only event log so at least the trail exists to trace which session actually received the reply. Called etch.systems, happy to share the hook shape if useful for reproducing or debugging.
Confirmed this on macOS as well, though it is intermittent and hard to reproduce reliably. The cross-session subagent reply misrouting appears to happen when two sessions have agents with the same agent name (e.g., both sessions use a "reviewer" agent definition from ~/.claude/agents/). The reply dispatch seems to key on agent name rather than a session-scoped identifier, so the first session to have a "reviewer" agent idle picks up the reply meant for the second session.
Reproducing steps that triggered it for us:
The workaround we found: prefix agent names with a short hash of the project path in each CLAUDE.md so that "reviewer" in project-foo becomes "reviewer-a3f1" and does not collide with "reviewer-b8c2" in project-bar. Clunky, but it has stopped the misrouting in our tests.
Would be useful to confirm whether Claude Code is using agent name alone or (session-id + agent name) as the dispatch key. If it is name-only, a session-scoped namespace is the minimal fix.