Cross-session messaging: silent socket-bind failure when multiple sessions start in the same second

Environment: Claude Code 2.1.226, macOS 26.5.1 (Apple Silicon, Mac mini). Sessions launched inside tmux by a launchd-triggered script.

Setup: 5 long-lived interactive sessions are (re)created by a watchdog script that calls tmux new-session -d -s <name> <launcher> five times back-to-back. Each launcher runs claude --model claude-opus-5 --name <name> --remote-control.

Observed: when several claude processes start within the same second, only one of them binds a cross-session messaging socket. For the others (4 out of 5 in our case):

• ~/.claude/sessions/<pid>.json is written but has no messagingSocketPath field
• no socket appears in /tmp/cc-socks/ for those pids
• they are invisible to ListAgents from peer sessions and never receive SendMessage deliveries
• no error or warning is surfaced anywhere — the sessions work normally otherwise, so the failure is completely silent and was only discovered days later when doorbell messages went nowhere

A session started alone a few minutes later bound its socket fine, and the same binary/flags are used for all five — the only variable is simultaneous startup, so this looks like a startup race (registration/bind contention), though we haven't traced the exact locus; hard evidence is the missing registry field plus the lone sock file.

Expected: each process binds its own /tmp/cc-socks/<pid>.sock (pids are distinct), or at least logs a visible warning and/or retries when binding fails.

Repro: start several claude --remote-control instances in the same second (e.g. tmux new-session in a tight loop); inspect ~/.claude/sessions/*.json for messagingSocketPath.

Workarounds that fixed it for us:

1. stagger launches by ~5s and verify messagingSocketPath appears after each start;
2. repair a live session without losing context: /exit in the pane, then claude --continue with the original flags — rebinding succeeds on restart.