DISABLE_TELEMETRY silently disables GrowthBook — which also gates preview features (Agent View) and remote killswitches
Summary
Setting DISABLE_TELEMETRY=1 (or DO_NOT_TRACK) puts Claude Code into a "no-telemetry" traffic mode that disables GrowthBook entirely. GrowthBook isn't only experiment-exposure logging — it's also the delivery mechanism for feature flags, which gate preview features (e.g. Agent View / claude agents / --bg / /bg) and remote killswitches. Net effect: a user who set DISABLE_TELEMETRY for privacy reasons silently gets a degraded product — with nothing logged (even at --debug) and nothing in the DISABLE_TELEMETRY docs to indicate feature-flag delivery is affected.
This isn't "please make me less private" — there's a legitimate privacy dimension (see Root cause). It's that the coupling is invisible and undocumented, and it pulls in things (killswitches) that have nothing to do with telemetry.
Reproduction
- Claude Code ≥ 2.1.139, OAuth subscription, no Bedrock/Vertex, no
disableAgentView, no managed settings. ~/.claude/settings.json→"env": { "DISABLE_TELEMETRY": "1" }(or export the env var).- Run
claude agentsin a normal terminal → prints the static agent-definition registry ("Project agents / Plugin agents / Built-in agents"), not the Agent View dashboard./bgand←-on-empty-prompt-to-background are also unavailable. - Remove
DISABLE_TELEMETRY→ start a fresh session (so flags re-hydrate) →claude agents→ dashboard appears. DISABLE_ERROR_REPORTINGandCLAUDE_CODE_DISABLE_FEEDBACK_SURVEYdo not have this effect — onlyDISABLE_TELEMETRY/DO_NOT_TRACK, because only those flip the traffic mode.
Confirmed: the same version (2.1.139) shows Agent View fine on a second machine that simply doesn't have DISABLE_TELEMETRY set.
Root cause (paths from the 2.1.139 build)
function G3q(){ if(env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC) return "essential-traffic";
if(env.DISABLE_TELEMETRY) return "no-telemetry";
if(env.DO_NOT_TRACK) return "no-telemetry";
return "default" }
function S7(){ return G3q()==="essential-traffic" } // note: "no-telemetry" is NOT this
function ja(){ return !env.DISABLE_GROWTHBOOK && Ja() } // isGrowthBookEnabled — Ja() appears false in "no-telemetry" mode
function f_(flag, default){ ...; if(!ja()) return default; ...; // getFeatureValue_CACHED_MAY_BE_STALE
return cachedGrowthBookFeatures?.[flag] ?? default }
function Xc(){ return !DWH() && (S7() || f_("tengu_slate_meadow", false)) } // isAgentsFleetEnabled
// `claude agents`: await ensureFleetGateHydrated(); if (Xc()) mountFleetView(); else → legacy registry list
With DISABLE_TELEMETRY set: G3q() → "no-telemetry" ⇒ S7() is false, and GrowthBook is disabled (ja() → Ja() resolves false — I didn't capture Ja()'s body, but empirically GrowthBook is off in this mode). So f_("tengu_slate_meadow", false) short-circuits to its false default — it never fetches the live flag, and the flag isn't in the bootstrap cachedGrowthBookFeatures either — ⇒ Xc() is false ⇒ claude agents falls through to the legacy handler.
The privacy dimension that makes this defensible: the GrowthBook client is configured remoteEval: true and ships an attributes payload on each refresh — N68() builds { deviceID, sessionId, platform, accountUUID, organizationUUID, userType, subscriptionType, rateLimitTier, appVersion, email, entrypoint, … } to https://api.anthropic.com/. So flag-value fetching does send an identifying bundle upstream; a "no telemetry" user arguably wants that off. The issue is the lack of transparency and the all-or-nothing-ness, not the existence of a tradeoff.
Impact
- Preview features silently absent. Agent View /
claude agents/--bg//bgis the visible one; presumably any other flag-gated rollout too. - Remote killswitches don't reach you. The flag set includes
*_killswitchentries (tengu_compact_line_prefix_killswitch,tengu_read_dedup_killswitch, …) and things liketengu_react_vulnerability_warning. With GrowthBook off you're frozen on whatever defaults shipped in your binary, and Anthropic can't push "disable the broken thing" / "warn about the bad thing" to you. This part has nothing to do with telemetry and is the strongest case for decoupling. - Zero signal. Nothing is logged (even with
--debug), and theDISABLE_TELEMETRYdocs (monitoring-usage / data-usage pages) describe it purely in terms of Statsig metrics / analytics — not feature-flag delivery. The only way I found this was disassembling the binary.
Why this reads like an un-revisited bundle, not a deliberate tier
There's already a separate DISABLE_GROWTHBOOK env var, and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC mode deliberately keeps the Agent View fleet gate on (S7() short-circuits Xc() to true). So the granularity exists — it just wasn't applied to DISABLE_TELEMETRY when GrowthBook started gating user-facing features.
For context, Agent View has at least three independent silent-disable paths in 2.1.139: (1) a wrapper/shell-integration injecting flags alongside claude agents (#58169, fixed in 2.1.140); (2) Bedrock/Vertex/Foundry or a custom ANTHROPIC_BASE_URL (#58284); and (3) DISABLE_TELEMETRY / DO_NOT_TRACK → no GrowthBook (this issue). This third one is the only one with neither documentation nor a log line.
Asks
- Document it. On the
DISABLE_TELEMETRY/ monitoring-usage / data-usage pages and the agent-view page: note thatDISABLE_TELEMETRY/DO_NOT_TRACKdisable the GrowthBook feature-flag layer (distinct from the Statsig metrics opt-out the docs currently describe), that feature flags gate preview features and remote killswitches, and thatDISABLE_GROWTHBOOKis the dedicated knob if zero flag-fetch traffic is the goal. - Decouple (preferred). Separate flag-value delivery from experiment-exposure logging.
DISABLE_TELEMETRYshould suppress exposure events but still allow flag values to be fetched — ideally with a minimal/anonymous attribute set andremoteEvaloff, so nothing identifying leaves the machine. KeepDISABLE_GROWTHBOOKas the explicit "no flag traffic, accept frozen defaults" escape hatch. - At minimum, surface it. A one-line
--debugnote when GrowthBook is suppressed, and/or a hint on theclaude agentsfallback:Agent View unavailable — feature flags disabled by DISABLE_TELEMETRY (see DISABLE_GROWTHBOOK).
Related
- #45381 — "Disabling telemetry also disables 1-hour prompt cache TTL" (closed / completed,
bug·has repro). Same pattern:DISABLE_TELEMETRYsilently degrades an unrelated capability that should be independent of telemetry. Precedent that this class of report is in-scope and gets fixed. - #53899 — "DISABLE_NONESSENTIAL_TRAFFIC silently disables security updates — unbundle DISABLE_AUTOUPDATER" (open,
enhancement·area:security). Sibling argument for unbundling a safety-relevant behavior from a convenience flag; the "remote killswitches" impact here is the direct analogue of its "CVE patches" impact. - #19117 — "Telemetry Configuration Ambiguity: Statsig vs OTel". The public docs describe
DISABLE_TELEMETRYas opting out of Statsig telemetry; they don't mention the GrowthBook feature-flag layer at all, which is what 2.1.139 uses and what gates Agent View. - #58169 (wrapper-injected flags, fixed in 2.1.140) and #58284 (3P-provider / custom-base-URL hard-disable) — the other two silent-disable paths for Agent View.
Environment
- Claude Code 2.1.139 (macOS arm64, native install)
- Auth: Claude.ai OAuth subscription; not Bedrock/Vertex/Foundry; no custom
ANTHROPIC_BASE_URL - No
disableAgentView, noCLAUDE_CODE_DISABLE_AGENT_VIEW, no managed settings - Repro is purely toggling
DISABLE_TELEMETRYin~/.claude/settings.json
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate of any of these, though #29580 and #47558 are close cousins (the maintainers may reasonably want to consolidate — see the end).
'--bg' is not enabled… retry in a momenterror, with noDISABLE_TELEMETRYinvolvement (a commenter notes it works fine without it). Looks like the daemon/fleet-gate not being hydrated yet — not this root cause.DISABLE_TELEMETRY⇒ experiment gates aren't fetched ⇒ the feature reads its built-in default), but a different feature surface (claude remote-control), and it was filed at 2.1.63 (Feb), well before Agent View existed. This issue is the Agent View (claude agents/--bg//bg) instance of that class.env-vars.md") and also predates Agent View, so its examples are prompt-cache TTL and/loop. This issue adds: the Agent View instance (current, high-visibility); the remote-killswitch impact (*_killswitchflags,tengu_react_vulnerability_warning— not a telemetry concern at all); the decompiled gate paths from the current 2.1.139 build; and two asks beyond documentation — (2) decouple flag-value delivery from experiment-exposure logging, and (3) surface the suppression in--debug/ theclaude agentsfallback hint.Happy for this to be folded into #47558 if the team would rather have one tracking issue — but the decouple/surface asks and the Agent-View + killswitch framing should land somewhere. Leaving it open for now.
Thanks for the thorough analysis — you correctly identified the coupling. We've removed the GrowthBook dependency from the Agent View gate, so
DISABLE_TELEMETRYno longer affects whetherclaude agents/--bgare available.Ships in v2.1.140 (just released). The broader point about killswitch coupling is noted.
@bogini Even if the concern wrt claude-agents etc is now fixed, should the killswitch issue not be moved to another ticket, if it is not yet fixed and/or documented?
Here is another issue on the topic of undocumented consequences of DISABLE_TELEMETRY: https://github.com/anthropics/claude-code/issues/34178
^ this was auto-closed after a while, but to paraphrase that thread "why close it, [if the] bug is still present?"?
The closure message is: "This issue has been automatically locked since it was closed and has not had any activity for 7 days"
What kind of activity? Do we need to actively comment in these threads, to prevent the issue(s) from being closed?
Or otherwise: "please file a new issue and reference this one if it's relevant."; This has to be done every month?
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.