Skip to content

Cross-machine peer relay via an agent-comms bridge #22

Description

@Mearman

cc-peer only ever sees local Claude Code sessions — ~/.claude/sessions, same-uid Unix socket or named pipe. There's no cross-machine leg, and there deliberately shouldn't be one built into cc-peer's own protocol handling: Claude's own cloud bridge is device-attestation-signed with a non-extractable key, which is a real boundary to respect, not a gap to work around.

The clean path is a cc-peer bridge for agent-comms (ExaDev/agent-comms), the same shape as its existing pi/claude-code/codex/mcp/opencode bridges. cc-peer stays exactly what it is today — a local peer speaking Claude Code's own protocol — and the bridge process is the thing that also joins the local agent-comms mesh and forwards traffic both ways.

Cross-machine reach then comes from agent-comms' own transport, not anything cc-peer has to build: its federation layer today, moving onto wire-mesh's relay/capability-token model per ExaDev/agent-comms#51. cc-peer doesn't need to depend on wire-mesh, or on agent-comms' transport internals, at all — only on the bridge existing.

Blocked by ExaDev/agent-comms#87 (the bridge itself).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions