coderClaw

Bridge protocol (legacy node transport)

The Bridge protocol is a legacy node transport (TCP JSONL). New node clients should use the unified Gateway WebSocket protocol instead.

If you are building an operator or node client, use the Gateway protocol.

Note: Current CoderClaw builds no longer ship the TCP bridge listener; this document is kept for historical reference. Legacy bridge.* config keys are no longer part of the config schema.

Why we have both

Transport

When TLS is enabled, discovery TXT records include bridgeTls=1 plus bridgeTlsSha256 as a non-secret hint. Note that Bonjour/mDNS TXT records are unauthenticated; clients must not treat the advertised fingerprint as an authoritative pin without explicit user intent or other out-of-band verification.

Handshake + pairing

  1. Client sends hello with node metadata + token (if already paired).
  2. If not paired, gateway replies error (NOT_PAIRED/UNAUTHORIZED).
  3. Client sends pair-request.
  4. Gateway waits for approval, then sends pair-ok and hello-ok.

hello-ok returns serverName and may include canvasHostUrl.

Frames

Client → Gateway:

Gateway → Client:

Legacy allowlist enforcement lived in src/gateway/server-bridge.ts (removed).

Exec lifecycle events

Nodes can emit exec.finished or exec.denied events to surface system.run activity. These are mapped to system events in the gateway. (Legacy nodes may still emit exec.started.)

Payload fields (all optional unless noted):

Tailnet usage

Versioning

Bridge is currently implicit v1 (no min/max negotiation). Backward‑compat is expected; add a bridge protocol version field before any breaking changes.