Messages are encrypted between the Pairlet client and daemon. The relay routes ciphertext and stores routing credentials, public keys, hashes, and timestamps—not prompts, code, private keys, or session keys.
- Key agreement
- P-256 ECDH + HKDF-SHA256
- Message encryption
- AES-256-GCM
- Daemon authentication
- Ed25519 challenge signature
Data path
Client → relay → daemon → Claude Code or Codex CLI. The daemon makes an outbound connection, so the default relay workflow does not require opening an inbound port on your computer. TLS protects each relay connection; an additional end-to-end channel protects content across the relay.
Pairing and identity
The daemon creates a static Ed25519 identity and a P-256 encryption identity. A client creates its own P-256 key. To pair, pairlet pair obtains a short-lived, one-use ticket and a 6-digit code from the relay; the QR code carries only that code. The client resolves the code through the relay to get the daemon public key and ticket, and the relay forwards the client's public key to the daemon. Because both public keys pass through the relay at this step, first-time pairing currently relies on the relay not being compromised. After pairing, every handshake authenticates the two pinned static keys, so the relay cannot read or forge the session. A later release will remove the reliance on the relay during pairing.
To check a pairing, run pairlet devices on the computer and compare it with "This device's fingerprint" and "Computer fingerprint" in the app (Settings → Support & about → About; desktop app: Settings → About). All five groups must match. Revoke any row you do not recognise with pairlet devices revoke. See the full trust model.
What the relay stores
| Category | Relay can store or observe | Relay is designed not to receive |
|---|---|---|
| Persistent data | Account fingerprint, public keys, credential and ticket hashes, timestamps, revocation state | Private keys, prompts, code, transcript content, session encryption keys |
| Connection metadata | Source IP, online timing, ciphertext size and timing, account-to-device routing graph | Plaintext message bodies |
| Logs | Connection lifecycle, authentication result, rate limits, byte counts | Decrypted frames |
What end-to-end encryption does not protect
- A compromised endpoint: the paired client and computer necessarily see plaintext.
- Local execution authority: the daemon drives a CLI process with the operating-system user's permissions.
- Traffic metadata: the relay can observe IP addresses, connection times, and encrypted frame sizes.
- Unsafe agent configuration: full-auto or permissive sandbox settings can allow commands without per-step approval.
Encryption is not a sandbox. Whatever the agent is allowed to do, it does with the operating-system user's own permissions on the paired computer. Approval enforcement also differs by agent backend: OpenCode sessions have no enforceable interactive approval and run at full access, and DeepSeek does not bridge remote approvals. See the capability matrix.
Known limitations
- The custom Noise-style channel has not received an independent security audit.
- The documented mobile key storage uses app-private storage rather than hardware-backed iOS Keychain or Android Keystore.
- Pair-ticket association uses a recent-ticket heuristic intended for sequential interactive pairing.
- Firebase Analytics and Crashlytics may send enumerated product events and crash information directly to Google. The project says these events exclude prompts, code, and session content; this telemetry does not pass through the relay and is separate from the relay's zero-knowledge claim.
How to verify or report a problem
The protocol, relay, daemon, and clients are available under the MIT license. The repository documents smoke tests that inspect the encrypted data plane and protocol tests for mismatched keys. Report vulnerabilities through GitHub private vulnerability reporting, not a public issue.
Primary sources
- Pairlet security and trust model (full protocol, stored fields, threat table, verification steps, and limitations).
- Shared end-to-end protocol implementation.
This page summarizes project documentation; it is not a third-party security audit.