Security · End-to-end encryption

Our servers cannot read your Session conversations or their history.

Your Session prompts, AI replies and conversation history are encrypted before they leave your computer. Clawdline Cloud forwards ciphertext. The content key needed to decrypt it is shared only with your computer and paired browsers; our servers do not hold it.

Compare Claude Code and Codex security reviews of four tools

Questions you send to support

Questions you explicitly submit in the help center are stored in the Cloud support database so our support team and answering Agent can read and reply to them. They are separate from encrypted machine Sessions. Do not include passwords, API keys or private Session conversations. Public FAQs are separately authored anonymous answers reviewed before publication.

How it works

From your computer to your phone: where is content readable?

Only at the two ends you own. In between, Cloud carries a sealed envelope it has no key for.

  1. Holds the content key

    Your computerwhere the Session runs
    • Readable conversation
    • Content key

    1Encrypt locallyAES-256-GCM, then signed with the device key.

  2. No content key

    Clawdline Cloudrelay and account service
    • Ciphertext onlyct: 7fA…9xQ
    • Key slot is empty

    2Forward ciphertextRouted by the outer fields; ct stays sealed.

  3. Holds the content key

    Your paired browserphone or another computer
    • Key received at pairing
    • Shown on your device

    3Verify, then decryptCheck the signature, decrypt with the paired key.

How the key reaches the browserAt pairing, the computer encrypts the content key for that browser. When the handover passes through Cloud, the server receives only ciphertext.

Replies travel the other way: the browser encrypts and signs; the computer checks permission before acting. Ciphertext shown is illustrative.

The data boundary

What Cloud can and cannot see.

EncryptedContent Cloud cannot read

  • Conversation historyevery transcript you open or page through
  • Prompts and AI replieswhat you ask and what comes back
  • Code and file contentsincluding file paths and repositories
  • Handoff documents and attachmentswhat one Session passes to another
  • Schedules and task instructionsincluding a task's claims and its commands

All of it travels inside the sealed ct field.

MetadataInformation Cloud can still see

  • Account and subscription
  • Machines and devicesnames, platforms, public keys
  • Connection times and byte counts
  • Outer routing fieldsconversation content travels separately as ct ciphertext

Encryption protects content; it does not hide all usage activity. Every field, listed

  • AI providers. This covers content sent through Clawdline's encrypted channel. The AI services you use in a Session still process prompts and replies under their own data policies.
  • Company policy. If your company prohibits work data from passing through external services, assess Cloud against that policy even when the data is encrypted. You can also use Clawdline locally without enabling Cloud.

Pairing

How does your browser get the key?

Signing into Cloud establishes your identity; it does not give your browser the content key. You pair it with the computer separately.

  1. You authorize pairing through the computer’s pairing command or pairing assistant. The two set up a one-time encrypted handover channel.
  2. The computer encrypts the content key for that browser. Even when the handover travels through Cloud, the server receives only ciphertext.
  3. The endpoints keep the key. Cloud does not escrow a content key that support can retrieve. A browser that loses its key must pair again.

Signing keys prove which device sent a message; content keys decrypt it. Cloud may hold a public signing key to verify signatures; that public key cannot decrypt conversations or sign as your device.

History

Is conversation history uploaded as a Cloud backup?

No. Your computer remains the source of conversation history.

When you open a Session or page through history in Cloud, the computer supplies the matching encrypted content in response to reads and live updates. This read path does not upload your entire conversation archive as a cloud backup.

The relay temporarily caches the latest encrypted envelopes for some channels in memory to help connections catch up. Those envelopes are not a searchable, readable conversation database. End-to-end encryption does not mean data never passes through a server.

Open source

Let your security team inspect the source

You do not have to take this page on trust. The Clawdline daemon and browser client are open source, and each link opens the code behind one step of the diagram.

We have no server-side conversation decryption key and no decryption back door for support to open your Session history. These files show how keys are handed over, where content is encrypted and where it is finally decrypted.

Links are pinned to the source revision reviewed for this page. Source availability enables inspection; it is not a third-party security audit. Inspect the open-source client · Explore encryption and pairing

Trust assumptions

What this protection depends on

End-to-end encryption moves trust to your endpoints. Three limits are worth knowing.

01Protect your computer and paired devices

A device that displays a conversation can read its plaintext. If a computer, browser or its keys are compromised, end-to-end encryption cannot protect content decrypted there. Pair only devices you trust.

02Your browser must trust the web application it receives

We serve the JavaScript for Cloud, so you still need to trust the web application we deliver. This page describes the protection in the current pairing and transport design; end-to-end encryption alone cannot prevent a website provider from publishing malicious code that reads content on an endpoint. If the website or deployment pipeline is compromised, malicious code could access decrypted content or keys in your browser. Our servers not holding decryption keys does not remove this supply-chain risk.

03Revocation cannot take back content already read

The computer checks pairing state and read permissions; Cloud-side revocation also depends on permission refresh. Revoking a device cannot erase plaintext it copied or make it forget keys it already held. In v2.1.0, revoking a Cloud device rotates the key for future content; remaining authorized devices recover the new key through an authenticated exchange. Previously read or copied content cannot be taken back.

Installation and device protection in v2.1.2

The installer uses trusted local Python 3 and OpenSSL 3 to verify the signed manifest and archive before executing downloaded code. Official macOS payloads are Developer ID signed and notarized; the app carries a stapled ticket. Paired devices can have read-only or operating permissions, with separate permissions for each Cloud browser. Cloud reads preserve existing pairings and can recover through the authenticated relay. A refresh that still fails appears in a dismissible status row without covering your work.

Download the published release · Inspect release verification · Read the bilingual agent review reports

Technical appendix: fields visible to the server

Outer fields support routing, verification and metering. Session content is inside the encrypted ct field.

Show envelope fields and account records

Envelope and connection information

v
envelope format version
ch
the channel: which machine and which session or handoff, by id
seq
position within that channel
ts
when the envelope was composed
class
one of stream, ctl, dispatch, ho — routing and billing, nothing finer
key_id
which content-key generation sealed it
nonce
random per envelope, public by necessity
ct
the sealed payload itself — we see that it is there and how many bytes it is, and nothing that is inside it
sender
which device composed it, by device id
sig
Ed25519 by that device over v, ch, seq, ts, class, key_id, nonce and ct — the routing fields and the ciphertext, and not sender
connection times
when a machine or viewer was connected
byte counts
how much moved, in and out

Account and device records

account
the identity you signed in with, and your subscription state
machines
each machine by name, platform and last seen — the same list the app shows you
devices
each phone or browser by name, platform, last seen, capabilities, and its public key
usage
the counts we bill and rate-limit from: dispatches, connect minutes, bytes, concurrent sessions

Cloud also handles service data for enabled features, such as push subscription endpoints and delivery results; notification content is encrypted by the computer. This envelope inventory is not a claim that these are the service's only account records.