The cc-peer leg of the cross-machine mesh epic: a Claude Code session without agent-comms installed is still reachable from the mesh, because the machine's coordinator bridge fronts it by default via cc-peer.
Identity model, the load-bearing decision: identity belongs to the (harness, cwd) agent slot, not to the bridge process. The session's own agent-comms bridge holds the slot when live; the cc-peer front holds it otherwise, using the same on-machine identity file, and always yields when a session-owned bridge appears. This gives continuity of addressing across restarts and across the front-to-own-bridge transition: peers' queued messages, room membership, and cross-machine addressing survive because the device-id never changes. It also makes dedup a structural invariant rather than a heuristic: one slot, one identity, one live front. A second Claude session in the same cwd behaves as agent-comms already does today (first takes the slot, second runs ephemeral).
Mechanics:
- The coordinator enumerates local Claude Code sessions via cc-peer and, for each, computes the slot the session's own bridge would hold, then probes that slot's lock by PID (the existing stale-lock probe). Live lock means the session fronts itself; skip. Otherwise the front attaches, holding the slot identity.
- Yield: when a session-owned bridge appears, the front detects the new lock and drops its relay presence; the session continues under the same identity.
- Relayed sessions are
visible by default, named from the cc-peer session name.
- Inbound delivery (mesh to Claude session) rides cc-peer's
send() into the session, matching what the existing one-shot bridge cc-peer command already does, generalised from an explicitly-invoked per-session bridge to a default coordinator responsibility.
cc-peer becomes an optional runtime dependency: absent sockets means no sessions to front, a clean no-op.
The cc-peer leg of the cross-machine mesh epic: a Claude Code session without agent-comms installed is still reachable from the mesh, because the machine's coordinator bridge fronts it by default via cc-peer.
Identity model, the load-bearing decision: identity belongs to the
(harness, cwd)agent slot, not to the bridge process. The session's own agent-comms bridge holds the slot when live; the cc-peer front holds it otherwise, using the same on-machine identity file, and always yields when a session-owned bridge appears. This gives continuity of addressing across restarts and across the front-to-own-bridge transition: peers' queued messages, room membership, and cross-machine addressing survive because the device-id never changes. It also makes dedup a structural invariant rather than a heuristic: one slot, one identity, one live front. A second Claude session in the same cwd behaves as agent-comms already does today (first takes the slot, second runs ephemeral).Mechanics:
visibleby default, named from the cc-peer session name.send()into the session, matching what the existing one-shotbridge cc-peercommand already does, generalised from an explicitly-invoked per-session bridge to a default coordinator responsibility.cc-peer becomes an optional runtime dependency: absent sockets means no sessions to front, a clean no-op.