Cloud & fleet

End-to-end encryption#

When cloud sync is on, the daemon encrypts content-bearing data with AES-256-GCM before it leaves the machine. The key stays local. The server stores ciphertext it cannot read, and your browser decrypts it when you open the dashboard.

The split#

Not everything is encrypted, and it is worth being precise about why.

Encrypted (`e2e`)	Plaintext
Session transcripts	Cost totals
Events and tool arguments	Token counts
Spans and traces	Session counts
External call detail	Health status
Search text	Node liveness
Session titles	Per-runtime and per-model daily rollups

The plaintext side exists so a summary can render before decryption and so the device display and push notifications can work at all — a lock-screen notification cannot decrypt anything.

This classification is structural, not per-push. Every shape in the query contract carries a trust class, and a shape marked e2e can never appear on a plaintext push list. That is enforced by the contract rather than remembered by whoever wrote the push code.

The key#

Generated on the machine, at connect time, and stored in ~/.clawmetry/. It is never sent to the server. The server has no copy, no escrow and no recovery path.

Which means, plainly: if you lose the key, the ciphertext is unrecoverable. That is the property you are asking for when you ask for end-to-end encryption, and it is a real trade-off rather than a marketing line.

bash

clawmetry connect --enc-key "$KEY"   # supply an existing key, e.g. for a rebuild

Back up your key with the rest of your configuration. To use the same key across several machines so one browser session can read them all, pass it explicitly when connecting each node.

Verifying it yourself#

You do not have to take this on trust. The wire is inspectable:

Point the daemon at a local endpoint that logs what it receives, using

CLAWMETRY_ENDPOINT.

Run a session with distinctive content.
Read what was captured, and search it for that content.

You should find the counters and not the content. That is the specific claim, and it is the one worth checking rather than a general assurance.

bash

CLAWMETRY_ENDPOINT=http://127.0.0.1:9999 clawmetry sync --foreground

Running from a repository checkout

If you do this inside a ClawMetry source tree, the local files shadow the installed package and you may be testing a different version than the one you run day to day. Verify from a clean directory.

What is still visible to the server#

Being complete about this:

That your node exists, its id, and when it last pushed.
Aggregate counters — how much you spent, how many sessions, on which

runtimes and models.

Metadata shape — the size and cadence of pushes.

If the fact that you use a particular model at a particular volume is itself sensitive, the cloud is not the right deployment for you. Use local-only or self-hosted.

Transport#

Encrypted payloads travel over TLS as well — the ciphertext is not an excuse to skip transport security.

Variable	Effect
`CLAWMETRY_CA_BUNDLE`	Custom CA bundle, for a corporate TLS-inspecting proxy
`CLAWMETRY_TLS_NO_VERIFY`	Disable verification. Do not, except when diagnosing a TLS problem you are actively fixing.

A frozen desktop bundle carries its own trust store; if TLS fails there but works from a pip install, that is the difference to look at.

Self-hosted#

The same encryption applies when pushing to your own endpoint — CLAWMETRY_SELF_HOSTED_E2E controls it. Running the server yourself and disabling end-to-end encryption is a coherent choice if you also own the storage; keeping it on means even your own server cannot read the content.

→ Self-hosted ingest

Redaction#

Encryption protects data in transit and at rest on the server. It does not stop a secret being in a transcript in the first place.

bash

export CLAWMETRY_REDACT=1

→ Hardening

Edit this page View as Markdown Report an issue