Claude Code Telemetry: What It Sends, Measured at the Proxy

The phrase people type is does Claude Code send telemetry, and the second one is how to disable Claude Code telemetry. The third, CLAUDE_CODE_ENABLE_TELEMETRY, is the one that causes trouble, because that variable does not control what Anthropic receives. It turns on an OpenTelemetry exporter that sends metrics to a collector you run. Anthropic’s own telemetry is on by default and has a different switch. I run claude -p unattended about ten times a day from a Mac mini and had never set any of these, so on September 2 I put a logging proxy in front of the binary and counted what it connects to.

Method: a proxy that logs hostnames and nothing else

Claude Code honors HTTPS_PROXY; I confirmed that in the WebFetch measurement earlier the same day, where a dead proxy port produced ECONNREFUSED. So the whole experiment is a 40-line Python HTTP CONNECT proxy on 127.0.0.1:8899 that appends one line per tunnel request, host:port plus a timestamp, and then forwards bytes without decrypting them. I cannot see paths or payloads. I can see every host the process asked to reach.

# the only part that matters
if parts[0] == "CONNECT":
    host, port = parts[1].rsplit(":", 1)
    log.write(f"{time.strftime('%H:%M:%S')} CONNECT {host}:{port}\n")
    upstream = socket.create_connection((host, int(port)), timeout=15)
    client.sendall(b"HTTP/1.1 200 Connection Established\r\n\r\n")
    pipe(client, upstream)

Each run was the same command in an empty directory, on Claude Code 2.1.258 with a Max subscription, so no project settings, no CLAUDE.md, one turn:

HTTPS_PROXY=http://127.0.0.1:8899 HTTP_PROXY=http://127.0.0.1:8899 \
  claude -p "Reply with exactly the word OK and nothing else." --output-format json

I ran it four ways: with no telemetry variables, with DISABLE_TELEMETRY=1, with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, and with DISABLE_TELEMETRY=0, which the docs say still opts out. Then I repeated the first and third with --debug-file so the tool’s own log could name what the connections were doing. Six runs, six answers of OK, $1.36 in total by the JSON cost field.

What connected

Three hosts appeared across all six runs, and only one of them is the thing people are asking about.

Host	Default	DISABLE_TELEMETRY=1	NONESSENTIAL=1	What it is
api.anthropic.com	13	10	2	The model, plus everything else Anthropic-side: feature flags, the bootstrap fetch, the list of my claude.ai MCP servers, usage metrics
mcp-proxy.anthropic.com	1	3	3	The Supabase connector attached to my claude.ai account, reached through Anthropic’s MCP proxy. Not telemetry; the count varies with reconnects
http-intake.logs.us5.datadoghq.com	1	0	0	Datadog’s log intake, US5 site. The “third-party logging infrastructure” the docs mention, by name

The Datadog connection is the concrete answer to the first question. In the default configuration it opened four to six seconds after start, at process exit, once per run, and it was absent in every run that set either opt-out variable. The data usage page describes this channel as latency, reliability and usage patterns, sent to Anthropic and to third-party logging infrastructure, never including code, prompts or file paths. I did not decrypt it, so I can confirm the destination and the timing, not the contents.

The error-reporting channel never showed up. The binary contains the endpoint, o1158394.ingest.us.sentry.io, next to *.ingest.us.sentry.io in what looks like an allowlist, but a clean one-turn run has no crash to report. Per the docs this channel is on only for Pro and Max sign-ins on 2.1.198 or later, connecting directly to the Claude API, and it has its own switch, DISABLE_ERROR_REPORTING. A Hacker News commenter watching with Little Snitch in April reported the same pair of hosts: api.anthropic.com and Sentry.

Where the other eleven connections went

DISABLE_TELEMETRY=1 removed the Datadog connection and three of the thirteen to api.anthropic.com. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 removed eleven of them, leaving two. The debug logs of the default and the nonessential run differ in 46 lines once you strip IDs and timings, and the network-related ones name what disappeared:

< [Bootstrap] Fetching
< [Bootstrap] Fetch ok
> [Bootstrap] Skipped: Nonessential traffic disabled
> Failed to fetch Grove notice config: essential-traffic-only
> Plugin autoupdate: skipped (auto-updater disabled)
< mcp runtime arm: v2 (source: growthbook)
> mcp runtime arm: v1 (source: default)
> hooks modules not loaded: ... GrowthBook is off for this session:
      a third-party provider, or telemetry opted out

That last pair is the part the search phrase does not prepare you for. The feature-flag fetch, GrowthBook, rides on the same opt-out as telemetry, and the flags decide real behavior. In my nonessential run the MCP client runtime silently dropped from v2 to v1. The env-vars reference lists what else goes with it: auto mode as the default on Pro, Max and Team, Remote Control, messaging sessions on other machines, claude import, the advisor tool, artifact comments, and Claude-drafted feedback. Every one of those is off in a session with DISABLE_TELEMETRY, DO_NOT_TRACK, DISABLE_GROWTHBOOK or the nonessential flag set.

Also visible in the default run’s log, and worth quoting because it is the source of the naming confusion:

[3P telemetry] isTelemetryEnabled=false (CLAUDE_CODE_ENABLE_TELEMETRY=undefined)

“3P telemetry” is your OpenTelemetry pipeline, third-party from Anthropic’s point of view, and it is off unless you set CLAUDE_CODE_ENABLE_TELEMETRY=1 and an OTEL_* exporter. Anthropic’s channel logs under a separate [Anthropic telemetry] prefix since 2.1.248, because before that its failures were printed as [3P telemetry] OTEL diag error and people thought their collector was broken. The monitoring page is entirely about the first kind. Setting its variable to 0 disables nothing that Anthropic receives.

The =0 trap, confirmed by the cache

The docs say DISABLE_TELEMETRY is checked for presence, so 0 and false still opt out. The proxy agreed: the =0 run made the same thirteen connections as the =1 run and no Datadog call. The prompt cache agreed more precisely. The =1 run wrote 18,886 tokens of cache and read 10,216; the =0 run wrote nothing and read 29,102, which is exactly that sum, meaning the two runs sent a byte-identical system prompt. The default run’s cache prefix was a different size, 19,157 tokens written, so the opt-out state changes what the model is told as well as what leaves the machine. DO_NOT_TRACK is the exception, parsed as a normal boolean, where 0 leaves telemetry on.

What opting out has cost people

The reason I checked the cache fields at all is issue #45381, filed April 8 with 163 reactions: sessions with DISABLE_TELEMETRY=1 were silently falling back from the one-hour prompt cache to the five-minute one, which on a Max plan meant re-billing the whole context after any pause longer than five minutes. Anthropic’s Boris Cherny replied on April 13 that a fix was going out, and a user confirmed it in 2.1.108 the next day with a table of ephemeral_1h_input_tokens across all three settings. On 2.1.258 all four of my runs reported the one-hour tier, so this is fixed, but the changelog shows it was one of a series. I went through all 6,179 lines of the CHANGELOG for telemetry entries; these are the ones about the opt-out itself, dated by npm publish time:

Version	Date	Change
2.0.17	2025-10-15	Nonessential-traffic flag also stops release-notes fetching; OTel exporters gain proxy support
2.1.105	2026-04-13	Fixed: the flag in one project’s settings permanently disabled usage metrics for every project on the machine
2.1.108	2026-04-14	Fixed: subscribers with DISABLE_TELEMETRY fell back to the 5-minute cache TTL (#45381)
2.1.120	2026-04-24	Fixed: the opt-out did not suppress usage metrics for API and enterprise users
2.1.198	2026-07-01	Error reporting turned on for Pro and Max sign-ins (per the data-usage page)
2.1.246	2026-08-25	Fixed: telemetry requests to Anthropic carried the API key configured for a third-party gateway
2.1.248	2026-08-27	Anthropic telemetry failures logged as [Anthropic telemetry] instead of [3P telemetry]
2.1.257	2026-09-01	Gateway model discovery now runs even under the nonessential flag, since it only touches your gateway

Read as a list, the pattern is that the opt-out has twice failed open, once leaked a credential, and once quietly made sessions more expensive. If you set these variables, the version you are on matters, which is a reason to read why a fleet stops updating before you also set DISABLE_AUTOUPDATER.

Which switch does what

Six variables overlap here, and the docs scatter them across four pages. This is the consolidated table, checked against the env-vars reference and the data-usage page on 2026-09-02:

Variable	Stops	Also stops	How it reads its value
DISABLE_TELEMETRY	Usage metrics to Anthropic and Datadog	Feature-flag fetching, the session survey	Any non-empty value, including 0
DISABLE_ERROR_REPORTING	Crash reports to Sentry	Nothing else; flags keep working	Any non-empty value, including 0
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC	Both of the above	Auto-updates, release notes, /feedback, the bootstrap fetch, availability checks, plugin command refreshes	Any non-empty value, including 0
DO_NOT_TRACK	Same as DISABLE_TELEMETRY	Feature-flag fetching	Boolean: 0 leaves it on
DISABLE_GROWTHBOOK	Feature-flag fetching only	Nothing; telemetry stays on	Boolean
CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY	The “How is Claude doing?” prompt (#8036, 134 reactions)	Nothing	Boolean

Two things none of them touch. The WebFetch hostname check still goes to api.anthropic.com before every fetch, with its own setting, skipWebFetchPreflight, covered in the WebFetch post. And a plugin can carry its own telemetry through its own hooks, which is what the Vercel plugin thread in April (280 points) was about; nothing in this table sees that traffic. All of these can be set under the env key in settings.json, and the managed-settings page shows {"env":{"DISABLE_TELEMETRY":"1"}} as the organization-wide form, with the warning that it also empties the org’s analytics dashboard.

What I am doing with it

Nothing, for now, and I want to be precise about why. This rig runs with --dangerously-skip-permissions under launchd, so the question of what leaves the machine is one I take seriously; the secrets audit exists for that reason. But the documented metrics exclude the things I would object to, the error reports are redacted before sending, and the opt-out drags the flag fetch with it. A headless session that loses feature flags gets the v1 MCP runtime and whatever else is gated that week, and I would rather find out about a behavior change from a changelog than from a job that silently ran differently. If I change my mind, the variable will be DISABLE_ERROR_REPORTING, the only one in the table that costs nothing else.

The proxy script, the launchd wrapper it ran under and the claude -p guardrails from this rig are in the Playbook.

FAQ

Does Claude Code send telemetry by default?

Yes, on the Anthropic API. In a default one-turn claude -p run on 2.1.258 I counted 13 TLS connections to api.anthropic.com and one to http-intake.logs.us5.datadoghq.com, Datadog’s log intake, at process exit. Bedrock, Vertex and Foundry sessions default to off. The documented contents are latency, reliability and usage patterns, without code, prompts or file paths.

How do I disable Claude Code telemetry?

Set DISABLE_TELEMETRY=1 in your shell or under env in settings.json. It stops the usage metrics and the Datadog connection, but it also stops feature-flag fetching, which turns off default auto mode, Remote Control and other gated features. Use DISABLE_ERROR_REPORTING=1 for crash reports alone. Do not use 0 to re-enable either one; both treat any non-empty value as off.

What is CLAUDE_CODE_ENABLE_TELEMETRY?

It enables OpenTelemetry export from Claude Code to a collector you configure with OTEL_* variables. It is off by default and does not affect Anthropic’s own telemetry. The debug log labels it [3P telemetry]; Anthropic’s channel is labeled [Anthropic telemetry] and is controlled by DISABLE_TELEMETRY.

Sources and method: six claude -p runs on 2026-09-02 between 19:36 and 19:39 KST, Claude Code 2.1.258, Max subscription, from an empty directory on one Mac mini, each routed through a local Python CONNECT proxy that logged tunnel targets only; counts and timings are from that log, cache and cost figures from the --output-format json output, and the attribution of connections from two --debug-file logs diffed after stripping IDs. Hostnames for Sentry and Datadog were read from the 2.1.258 binary with strings; I did not decrypt any traffic, so what those services receive is stated only as the docs state it. Documentation quotes are from the linked pages as served that day, version dates from the npm registry, and the two GitHub issues and the HN threads were read in full. Some links are affiliate links; commissions, when any exist, land on the public ledger.