iTerm2 teammates don't receive messages: initialization race condition in v2.1.32

Bug Description

When spawning teammates in iTerm2 split panes, the teammate processes fail to recognize themselves as teammates due to a race condition during initialization. Messages sent via SendMessage are correctly written to inbox files but never consumed by the teammate processes.

Environment

• Claude Code version: v2.1.32
• OS: macOS (Darwin 24.6.0, arm64)
• Terminal: iTerm2 with it2 CLI installed
• Settings: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1"

Steps to Reproduce

1. Start Claude Code in iTerm2
2. Use the Teammate tool to create a team (spawnTeam)
3. Use the Task tool with team_name and name parameters to spawn teammates
4. Teammates appear in iTerm2 split panes with correct flags (--agent-id, --agent-name, --team-name)
5. Send messages to teammates via SendMessage
6. Teammates sit at the initial prompt and never process incoming messages

Root Cause

Found by extracting and analyzing the bundled cli.js source and cross-referencing with debug logs.

Initialization order bug:

1. Teammate process starts with correct CLI flags: --agent-id X --agent-name Y --team-name Z
2. The React app renders and calls computeInitialTeamContext() during reconnection setup
3. computeInitialTeamContext checks getDynamicTeamContext() (the module-level ET variable), which returns null
4. setDynamicTeamContext() is called later from CLI arg parsing (after the React tree has already rendered)
5. Result: The process never establishes its team context

Consequence: The InboxPoller component checks JT6() (which internally calls isTeammate() → checks ET?.agentId && ET?.teamName), gets undefined, and sets the polling interval to null — so it never polls the inbox.

Debug Log Evidence

From the teammate's debug log (~/.claude/debug/{session-id}.txt):

2026-02-06T00:07:03.450Z [DEBUG] [Reconnection] computeInitialTeamContext: No teammate context set (not a teammate)
2026-02-06T00:07:03.466Z [ERROR] Error: Error: getTeammateModeFromSnapshot called before capture - this indicates an initialization bug
2026-02-06T00:07:03.466Z [DEBUG] [TeammateModeSnapshot] Captured from config: tmux

Note: There are no subsequent recovery logs — the team context is never established after the initial failure.

Inbox File Evidence

Messages are correctly written to ~/.claude/teams/{team}/inboxes/{agent}.json with "read": false, confirming the write path works but the read/poll path never activates.

Relevant Source Locations (from bundled cli.js)

• computeInitialTeamContext — calls getDynamicTeamContext() which returns null too early
• setDynamicTeamContext — called from CLI arg parsing: oTq().setDynamicTeamContext?.({agentId, agentName, teamName, ...})
• InboxPoller (Gjq) — polls every 1000ms via useInterval, but only if JT6() returns a valid agent name
• JT6 — returns undefined when isTeammate() is false (because ET is null)

Expected Behavior

setDynamicTeamContext should be called before the React component tree renders, so that computeInitialTeamContext and InboxPoller can correctly identify the process as a teammate.

Workaround

None found. The useEffect fallback path in vDq checks getDynamicTeamContext again, but by that point the initial state is already set without team context and the recovery doesn't trigger.