Messages are encrypted between the CC Pocket 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. Pairing transfers the daemon public key and a short-lived, one-use ticket through a QR code or pairing link. The ticket is mixed into the first handshake as a pre-shared secret, so replacing a forwarded client key causes the handshake to fail.
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.
Folder sharing is a scope, not a sandbox. A guest session can be fenced to a folder in the product, but shell commands still execute as the owner's operating-system user.
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
- CC Pocket 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.