Cloud routes your messages and cannot read them.
This page explains what Clawdline Cloud sees when it carries traffic between your phone and your machine, what it never holds, and the two keys that make that true.
Checked against the product on 6 October 2026
Latest release: Clawdline v2.9.0 · platform support
What Cloud sees, and what it never holds
- Cloud sees each message's routing shell: channel, class, sequence number, time, key id, sending device, and size. It also sees your account, your machines, and the public half of each device's signing key.
- Cloud never holds the content key, so it cannot read a prompt, a reply, a transcript, or code. It keeps nothing to forward later; the one exception is a webhook call, whose body (at most 64 bytes) only says "run it now" and never reaches the agent.
- Cloud never executes. Every Session runs on your machine, and transcripts and code stay there.
Two keys with different jobs
| Device signing key | Content key | |
|---|---|---|
| Job | Proves which device sent a message, with an Ed25519 signature | Encrypts every message body with AES-256-GCM |
| Made by | Each device for itself. A browser keeps it as a non-extractable WebCrypto key | Each machine for itself, the first time it connects. A browser gets it only by pairing |
| Cloud holds | The public half only | Nothing |
| Ends when | clawdline cloud revoke on the machine refuses that device at once | It is not rotated yet; clawdline cloud rotate replaces the machine's signing key, not this one |
A revoke from your account, rather than on the machine, stops routing at the next entitlement refresh. The security page gives the exact window under limit 2.
How a browser gets the content key
- Signing in at app.clawdline.com gives the browser an identity and nothing else.
- Pairing passes a one-time secret, never the content key. The two sides agree on a one-time key, and the machine seals the content key under it, so only ciphertext crosses Cloud.
- Both sides show key fingerprints at the same moment. When they match, no server put its own key in the middle.
- There is no escrow. A browser that loses the key pairs again; the content still lives on the machine, so nothing is lost.
What travels
Every message is one JSON envelope. Cloud routes by the plain fields; ct is ciphertext.
{
"v": 1,
"ch": "s/mac-studio/s_41c8",
"seq": 412,
"ts": 1787740000000,
"class": "stream",
"key_id": "ms-1",
"nonce": "…12 bytes",
"ct": "…ciphertext and tag",
"sender": "dev_a41c…",
"sig": "Ed25519 over v|ch|seq|ts|class|key_id|nonce|ct"
}A reply to one request is sealed under a one-time reply key that came inside the request, not under the content key.
Commands are signed and encrypted
Cloud cannot compose a command. A command from a browser is signed by that device's key and
encrypted under the content key, and the machine checks both before it acts. The machine also
refuses every command until you allow operation in that machine's Settings → Remote (or run
clawdline cloud commands on). So a stolen Cloud
account is not a machine taken over.
Where to go deeper
- Security — the limits of this design, written out.
- Connect Clawdline Cloud — pair, allow commands, and revoke.