[DOCS] DISABLE_TELEMETRY should document experiment-gate side effects

I collected the actual Statsig cached evaluations and telemetry files from my Claude Code installation (v2.0.70–2.0.76) over ~4 months.

How I found this: I compared Claude Code with Claw-Code (the open-source fork from the March 2026 leak). The diff revealed what was stripped: Statsig integration, feature gates, A/B experiments, and telemetry infrastructure. From there I examined the local cache files Claude Code had already written to my machine. Ironically, Claude Code itself cannot identify its own surveillance infrastructure — I had to use the open-source version and local uncensored LLMs to analyze it.

73 files, 36 MB of raw data showing:

• 65 feature gates (22 ON, 43 OFF) — gate names hidden behind numeric IDs
• 4 active A/B experiments including variant_positive_attitude (behavioral manipulation)
• 47 dynamic configs controlling runtime behavior
• session_recording_rate: 1 (100% of sessions recorded)
• Telemetry export: every 5 seconds, batch of 200, queue of 8192

All PII has been redacted. Feature gates, experiments, and configs are intact.

Download sanitized evidence: https://gofile.io/d/Nf3eBO

This supports the issue: disabling telemetry doesn't just affect metrics — it changes which experiment gates are active, which directly affects Claude Code's behavior in ways users can't see or control.

Concrete data point for the Remote Control side effect.

On a direct Anthropic setup (claude.ai subscription auth, not an enterprise
provider like Bedrock/Vertex/Foundry), DISABLE_TELEMETRY=1 forces a genuine
either/or between two first-party features that need opposite
feature-flag-fetching states:

• Cross-session messaging / SendMessage is documented as available "in

sessions that run with feature-flag fetching off" → needs fetching OFF,
i.e. it effectively requires DISABLE_TELEMETRY=1 here.

• Remote Control needs feature-flag fetching ON to verify its rollout.

With the flag set, claude doctor reports:

• Feature-flag evaluation disabled (disabled by DISABLE_TELEMETRY)
• Remote Control rollout could not be verified for this account (no server response this session)

Net effect: you can have SendMessage or Remote Control, never both, and
nothing surfaces the conflict — the only hint is that one doctor line. Beyond
the doc note this issue asks for, a runtime warning when both are configured
would help. (Claude Code 2.1.232, macOS.)

Me and my Agent find some workaround for this:

Environment: Claude Code 2.1.296 (VS Code extension, native binary), Windows 10.

Summary

Setting DISABLE_TELEMETRY=1 does more than stop telemetry. It also switches off feature-flag evaluation, so every flag-gated feature silently falls back to its hard-coded default. For me the visible loss was the PowerShell tool. There is a way to keep telemetry off and get the features back; it is described below and verified in the VS Code extension.

What happened

I added "DISABLE_TELEMETRY": "1" to env in ~/.claude/settings.json. Every session started after that had Bash but no PowerShell tool. The same went for subagents, including one whose definition lists PowerShell. The version was the same before and after: all 11 sessions started before the change had the tool, all 3 started after it did not. Nothing in the session said why.

Cause

• With DISABLE_TELEMETRY set, the traffic mode is no-telemetry, and in that mode flag evaluation is off. The cached payload in ~/.claude.json (cachedGrowthBookFeatures) stays on disk but is not read, and cachedGrowthBookFeaturesAt stops moving.
• The PowerShell tool is a preview that was enabled for me only through a flag.
• The check is still truthy-only: if(process.env.DISABLE_TELEMETRY)return"no-telemetry", while DO_NOT_TRACK right next to it goes through a boolean parser. So DISABLE_TELEMETRY=0 should still count as opted out. I read this in the 2.1.296 bundle and did not test 0.
• Scope: of my 699 cached boolean flags I could match 301 to a default at a call site. 106 of those were on in the cache and default to off; 6 were off and default to on. This is a heuristic, but the opt-out clearly changes far more than one feature.

Workarounds (telemetry stays off)

1. PowerShell tool only: "CLAUDE_CODE_USE_POWERSHELL_TOOL": "1" in the settings env. The tool came back at once, in a session that was already running.
2. All flag-gated features: CLAUDE_CODE_GB_DISK_CACHE_WHEN_TELEMETRY_OFF=1. Flags are then read from the last payload cached on disk, and nothing is fetched.

Test for 2: three claude -p runs, each with DISABLE_TELEMETRY=1 and no user settings. The tool list comes from the init event of --output-format stream-json.

| Extra variable | Tools | PowerShell |
|---|---|---|
| none | 25 | no |
| CLAUDE_CODE_GB_DISK_CACHE_WHEN_TELEMETRY_OFF=1 | 28 | yes |
| CLAUDE_CODE_USE_POWERSHELL_TOOL=1 | 26 | yes |

Verified in the VS Code extension

I set the variable as a Windows user environment variable and restarted VS Code completely. In the next extension session:

• the variable and DISABLE_TELEMETRY=1 were both in the session's environment,
• the PowerShell tool was there, for the main session and for a subagent,
• two more tools appeared that the flag-less sessions did not have (Monitor, PushNotification),
• cachedGrowthBookFeaturesAt was unchanged, so the flags came from disk and nothing was fetched.

Caveats

• The variable must be in the environment the process is launched with. In the env block of settings.json it is ignored: it never reached the session's tool environment, while CLAUDE_CODE_USE_POWERSHELL_TOOL from the same block did. In the bundle it is on a list of names that are not accepted from settings.
• The cache goes stale. New rollouts and kill switches do not arrive while telemetry is off. One run with telemetry on should refresh it; I did not test that.
• I found the variable in the binary, not in the docs, so it may change or go away.

Side observation

With flags back, a plugin marked @synced (claude-security; its marketplace copy ships hooks) loaded again, although it is not in my enabledPlugins. It first appeared in the last session I started before the opt-out, was absent in every session with flags off, and came back now. So I assume it is flag-gated too. That is an inference from the correlation, not something I traced in the code.

Suggestions

• Parse DISABLE_TELEMETRY as a boolean, like DO_NOT_TRACK.
• Read the disk cache by default when telemetry is off, or document the variable and accept it from settings.
• Say so when a tool or command is unavailable because flag evaluation is off. The silence is what costs the time.