[BUG] Named agent spawn resolves the team file under a foreign session id (0/21 match) - Windows, 2.1.247 onward

Summary

Spawning a subagent with name: set fails with:

Internal error: team file for "session-<id>" not found. The session team should have been initialized at startup.

The <id> named in that error is never the current session's id. Across every named spawn that produced this error in one project's transcripts - 21 occurrences - the id in the message differed from the transcript's own sessionId. Match rate: 0 / 21.

Re-spawning without name: but with the identical subagent_type: succeeds immediately, so the specialist agent itself is fine. Only the team/mailbox registration path is broken.

This is distinct from #82627, which reports a different error string (Team config file unreadable (lock acquired, read failed)) with a macOS-specific root cause. Both error strings occur on this machine; see "Second error string" below.

Environment

• Claude Code 2.1.263 (live reproduction); regression first observed at 2.1.247
• Windows 11 Enterprise 26200, git-bash
• Single user account; ~/.claude/teams/ created and owned by that user

Reproduction

1. Start a session and note its session id.
2. Spawn any agent with name: set, e.g. Agent({ name: "probe", subagent_type: "Explore", prompt: "..." })
3. The spawn fails with the error above - naming a different session id.
4. Re-spawn with name: removed and everything else unchanged -> succeeds.

Live example on 2.1.263:

• current session: 1b331b27-...
• error: team file for "session-7470f9d6" not found
• 7470f9d6 is an unrelated session in the same project that had already ended roughly four hours earlier.

Evidence

The looked-up session id is never the current one

Every team file ... not found error in this project's transcripts, paired with the sessionId of the transcript it occurred in:

| error names | actual session | |
|---|---|---|
| session-7470f9d6 | 1b331b27 | mismatch |
| session-a751c891 | 2e09d1c5 | mismatch |
| session-c5759194 | b64b9ed0 | mismatch |
| session-b4ca5240 | e4bfa004 | mismatch |
| session-b466fcac | f5f9ec5e | mismatch |
| session-a4619db5 | 760859a0 | mismatch |
| ... 15 more rows ... | | mismatch |

21 occurrences, 0 matches.

Version correlation

Same project, same machine, same user account, 62 named spawns total:

| Claude Code | OK | ERR |
|---|---|---|
| 2.1.237 | 9 | 0 |
| 2.1.238 | 4 | 0 |
| 2.1.241 | 1 | 0 |
| 2.1.247 | 1 | 13 |
| 2.1.248 | 0 | 1 |
| 2.1.250 | 0 | 3 |
| 2.1.258 | 4 | 19 |
| 2.1.260 | 4 | 2 |
| 2.1.263 | 0 | 1 (live repro) |

At 2.1.241 and below: 14 OK / 0 ERR. At 2.1.247 and above: 9 OK / 39 ERR.

There is no usage data for 2.1.242 - 2.1.246 on this machine, so the exact breaking version is somewhere in that range or at 2.1.247.

The failing session's team directory is never created

• Before the failed spawn: no ~/.claude/teams/session-<current-id>/
• After the failed spawn: still none.

Only sessions whose named spawn succeeded have a directory. On this machine exactly 2 of the 6 session ids appearing in errors have a directory, and those 2 are precisely the 2 sessions that ever succeeded at a named spawn.

Not a permission problem

From the same user account, in the same shell environment Claude Code runs under:

| check | result |
|---|---|
| read an existing team inbox JSON | OK |
| create + delete a file in ~/.claude/teams/ | OK |
| create + delete a session subdirectory there | OK |
| mode / owner | drwxr-xr-x, owned by the running user |

The error is also not found, not permission denied, and it names a foreign session id - consistent with a wrong lookup key rather than an access failure.

Not (only) concurrency

Failure rate by the number of live Claude Code sessions on the machine at spawn time:

| live sessions | OK | ERR | failure rate |
|---|---|---|---|
| 1 | 15 | 16 | 52% |
| 2 | 6 | 20 | 77% |
| 3 | 2 | 2 | 50% |

Contention makes it worse, but the failure occurs at 52% with a single live session, so contention is an aggravating factor rather than the cause.

Second error string

Named spawns on this machine fail with one of two messages:

| message | count |
|---|---|
| team file for "session-X" not found | 21 |
| Team config file unreadable (lock acquired, read failed) | 18 |

The second is the string reported in #82627, but that issue's com.apple.provenance root cause is macOS-specific and cannot apply here (Windows). I have added a comment there with this counter-example. This issue covers only the first message.

Impact

• Mailbox/teammate addressing is unavailable for any agent that could not be named, so SendMessage({to: "<name>"}) cannot reach it.
• A reliable workaround exists: retry the spawn without name: and address the agent by the returned agent id. 73 / 73 such continuations succeeded here, and background completion notifications arrived for 244 / 245 launched agents.
• The practical damage is therefore limited to losing named addressing - but it fails on the majority of attempts, which quietly pushes every workflow onto the fallback path.

Expected behaviour

A named spawn should initialize and look up the team file for the current session, not for an unrelated session id.