Session starts without binding its cross-session peer socket — registered but unreachable by SendMessage; silent failure, restart fixes

Environment

• Claude Code 2.1.226, macOS 26.5.2 (Darwin 25.5.0), zsh, interactive terminal sessions
• Cross-session peer messaging in use (ListAgents / SendMessage over unix sockets in /tmp/cc-socks/)

Summary

A session can start in a state where it writes its peer-registry entry (~/.claude/sessions/<pid>.json) but never binds its inbound unix socket (/tmp/cc-socks/<pid>.sock). The session looks healthy from inside — outgoing SendMessage and ListAgents work — but any peer that tries to message it gets No agent named '<name>' is reachable. Nothing surfaces the failure to the user or to the session itself; it was only discovered when a reply to a handoff request bounced.

Observed timeline (2026-08-10, local UTC+3)

• 12:53 — session pid 78733 starts: socket bound normally, fully reachable.
• 13:04:43 — session pid 89561 starts: registry entry written (with empty status field), no socket ever created.
• 13:10:40 — session pid 97391 starts (sessionId b81564b7…, registry name bytes-c9, status busy): registry entry written, no socket ever created.
• ~13:12 — peer pid 78733 attempts SendMessage to bytes-c9 (both name [ref] and bare name): No agent named 'bytes-c9' is reachable. Its ListAgents did not list the session at all.
• 13:17 — verified from inside the affected session: lsof -U -p 97391 shows zero unix sockets under /tmp/cc-socks/; the registry JSON for it exists. Meanwhile its own outgoing SendMessage to pid 78733 had succeeded (sending dials the receiver's socket, so only inbound is broken).
• 13:30:30 — user restarts the affected session (same sessionId, new pid 20710): socket binds immediately, inbound delivery of the previously-bounced message succeeds.

Expected

A session either binds its peer socket at startup or surfaces the failure (log/status/warning), and doesn't register itself as an addressable peer while unreachable.

Actual

Silent partial initialization — registry entry present, listener absent, no error anywhere. Two independent sessions started within a ~6-minute window both hit it; sessions started before and after were fine (suggests a transient — possibly an auto-update replacing files during startup, though that's inference, not observed).

Impact

Cross-session workflows (handoffs, peer coordination) fail with a misleading "not reachable" error against a session that's demonstrably alive; the sender can't distinguish "closed" from "listener never bound". Stale sockets of dead pids (days old) also linger in /tmp/cc-socks/, so socket presence can't be trusted in either direction.

Workaround

Restart the affected session; file-based transfer as delivery fallback.