What OpenClaw sends home

You installed OpenClaw on your own machine precisely so that nothing would leave it. Then you read a release note, or you watch the firewall log, and there is an outbound request to telemetry.openclaw.ai once a day. It is worth knowing exactly what that request carries, what the receiving end keeps, and which parts you can switch off. The documentation is unusually specific about all three.

Two tiers, and only one of them is on by default

• The daily update check is the default tier. It is a plain GET to https://telemetry.openclaw.ai/api/latest-version asking whether a newer version exists, and it has no request body at all.
• Everything it tells the server travels in one header. A User-Agent like openclaw/2026.8.2 (darwin; node/26.0.1; arm64; gateway) carries the OpenClaw version, the operating system, the Node.js version, the CPU architecture, and whether the caller was the Gateway or the CLI.
• Neither tier includes message content, prompts, model names, API keys, credentials, file paths, hostnames, or account identifiers. There is no install identifier, no machine identifier and no random tracking identifier either: OpenClaw creates no persistent client id for these requests, which is why repeated reports are not a count of installations or of users.
• Anonymous feature statistics are the second tier, and they are off by default. When you enable them the same daily request becomes a POST carrying a small JSON body at schema version 1, instead of adding a second request.

Declining is a completely normal choice and changes nothing about how OpenClaw works for you.

Opt-in here really does mean opt-in

Interactive setup can offer a one-time opt-in with No thanks selected by default, and the guided Quick Start skips that prompt entirely. OpenClaw records your answer so setup stops asking, but the recorded answer is not what decides anything: the enabled setting is. Non-interactive and scripted installations never opt in on their own, so an image built in a pipeline stays on the update-only tier until an operator turns statistics on deliberately. The stated purpose of the second tier is narrow, informing maintenance priorities, and the docs are explicit that it measures no individual plugin invocation, no message, no model request, and no active user.

The field the client does not control

• Cloudflare supplies approximate location to the hosted receiver: country, region code, city, and timezone. No raw IP addresses and no precise coordinates are stored in analytics, and missing or invalid fields simply stay empty.
• Recorded update checks include those fields even when anonymous feature statistics are off and even when DO_NOT_TRACK is set. No extra client payload and no prompt are involved, because the values are derived at the edge rather than sent by you.
• Analytics Engine retains records for three months. Public aggregates exclude location information, and disabling requests later does not erase records that already exist.

Before you change anything, run openclaw telemetry show. It reports whether anonymous feature statistics are enabled and why, the request endpoint, and the last successful check, and when statistics are off it prints the update-only request together with its User-Agent header. Add --json for the same state and payload as one machine-readable document. When statistics are enabled the preview shows the whole payload, and it is short: schema, version, platform, node, surface, and a features object holding configured channel ids, provider families, public plugin ids, a total plugin count, and sessionsLast24h. Those plugin names cover bundled plugins, trusted official installs, and entries matching the official plugin catalogue, so private plugin identities are never named, and the difference between pluginsEnabled and the number of names reported is not a reliable count of private plugins. The session figure counts retained session-creation events timestamped in the preceding 24 hours, and not session activity. Two limits matter here: the payload preview is built inside the CLI process rather than retrieved from the running Gateway, so it is not a guarantee of the exact next Gateway payload, and it describes the client request only, so it can never show you the server-derived location. If the output says Request: none, an automation or update-check policy has already stopped everything. The preference itself is an ordinary key in the OpenClaw configuration file, and it is unrelated to provider usage tracking, which is about provider quota and cost.

Every way to turn the requests off

The command openclaw telemetry off disables anonymous feature statistics, and telemetry.enabled: false does the same thing from the config file. DO_NOT_TRACK=1 or DO_NOT_TRACK=true forces statistics off even when telemetry.enabled is true, but it deliberately leaves the daily update check in place as the body-less GET. To stop every automatic request, set update.checkOnStart: false, which disables both tiers and the update notice even when update.auto.enabled is true, and OPENCLAW_NO_AUTO_UPDATE=1 prevents automatic update requests as well. OpenClaw also sends nothing when the CI environment variable is truthy, on the argument that pipeline jobs would outnumber real operators and make version and platform counts meaningless, although setting OPENCLAW_TELEMETRY_ENDPOINT to your own replacement endpoint overrides that suppression, because a configured endpoint means the run is deliberately exercising this path. Explicit update commands remain available whenever you choose to run them, so updating OpenClaw on purpose stay in your hands, and the whole exercise sits naturally beside OpenClaw security practices.

On Diali

Diali runs Hosted OpenClaw on Diali as a hosted service. Each customer gets a separate assistant on its own instance rather than a seat on a shared one, and the runtime configuration is generated from your dashboard settings and written fresh at every release, so a hand edit made inside the container does not survive an upgrade while anything expressed in the dashboard does. Sessions, memory and the rest of the state live on a persistent volume, which is also where the cached result of a successful update check would sit; daily snapshots and one-click restore are available through the Backups add-on (included on Max). Diali pricing lists the plans.

• The daily update check is on by default and rides entirely in one User-Agent header.
• Anonymous feature statistics stay off until an operator turns them on.
• Approximate location is kept for three months, and switching requests off does not erase it.