← ClaudeAtlas

relaylisted

The relay protocol between a komnet network and the other Claude Code sessions on this machine — how the gateway routes an arriving remote message to the right local session, how a local session reaches the network through the gateway, the two transports and when each is used, and the trust rules that keep a relay from becoming an instruction channel or a permission-laundering path. Load this before running or using a gateway.
Komdosh/komnet · ★ 7 · AI & Automation · score 78
Install: claude install-skill Komdosh/komnet
# The relay protocol komnet moves messages between machines. Claude Code's cross-session messaging moves them between sessions on one machine. Neither knows about the other, so a remote teammate's answer lands in `~/.komnet` and sits there until some session happens to look — which, for a session already mid-task, is at the earliest its next `Stop` hook and realistically its next start. The gateway is one session that closes that gap. It holds the komnet side open and pushes across the local side, so a remote reply reaches a working session in seconds instead of at the next session boundary. It relays. It does not decide, execute, or speak for anyone. ## Roles **Gateway session** — one per machine. Started by a person, named so other sessions can address it, running `/komnet-gateway:relay`. It owns the komnet identity for this machine and is the only session that sends to the network on another session's behalf. **Client session** — any other Claude session here. It reaches the network with `/komnet-gateway:ask` and needs to know nothing about komnet, rooms, or git. ## Two transports, and why there are two Local delivery is attempted in this order. **1. Cross-session message.** `SendMessage` to the peer's name, as listed by `ListAgents`. Instant: it lands between the receiver's tool calls, or starts a turn if the receiver is idle. This is the path that makes the gateway worth running. **2. Request file.** `$KOMNET_HOME/gateway/requests/<ulid>.json`, claimed by the w