---
title: End-to-end encryption
description: How ClawMetry protects session content in the cloud — AES-256-GCM with a key that never leaves your machine, the plaintext split, and how to verify it yourself.
keywords: end to end encrypted agent telemetry, AES-256-GCM agent data, zero knowledge observability, encrypted agent transcripts
eyebrow: 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](/docs/data/query-api/) 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:

1. Point the daemon at a local endpoint that logs what it receives, using
   `CLAWMETRY_ENDPOINT`.
2. Run a session with distinctive content.
3. 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
```

:::warning 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](/docs/start/deployment-modes/) or
[self-hosted](/docs/cloud/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](/docs/cloud/self-hosted/)

## 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](/docs/config/security/)