[BUG] DISABLE_TELEMETRY=1 breaks remote-control with misleading "not yet enabled" error

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/28777

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I saw that issue. But I am not sure if this is a duplicate - the error message is different. But it might be the same root cause...

try unset CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC && claude rc

"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC" has not been enabled for me.

Therefore, unsetting does not change anything.

Additional finding: DISABLE_TELEMETRY=0 (explicitly "off") also triggers this bug

Environment

• Claude Code 2.1.69
• Fedora Linux + Windows 11
• Max plan, same account on both machines

Problem

The /remote-control slash command was completely missing from the command list on Linux, while the exact same account and version on Windows had it available. The command didn't even show up in /help - it wasn't just failing, it was hidden entirely.

Root cause (traced through source)

In cli.js, the command registration uses isEnabled: Zvq where:

Zvq() → vn() → qA("tengu_ccr_bridge", false)

qA() calls Ar() which calls !Pv():

function Pv() {
  return w1(process.env.CLAUDE_CODE_USE_BEDROCK) ||
         w1(process.env.CLAUDE_CODE_USE_VERTEX) ||
         w1(process.env.CLAUDE_CODE_USE_FOUNDRY) ||
         !!process.env.DISABLE_TELEMETRY ||        // <-- BUG HERE
         !!process.env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC
}

When Pv() returns true, qA() skips all GrowthBook/Statsig feature flag lookups and returns the default value (false) for every gated feature - including tengu_ccr_bridge.

The critical issue: DISABLE_TELEMETRY uses !! (truthy check) while the other env vars use w1() (proper boolean parse). Setting DISABLE_TELEMETRY=0 in settings.json produces process.env.DISABLE_TELEMETRY = "0", and !!"0" is true in JavaScript because "0" is a non-empty string.

So explicitly setting telemetry to OFF ("0") has the same effect as setting it to ON ("1") - both disable all feature flag evaluation, hiding /remote-control and potentially other gated features.

The cached GrowthBook features in ~/.claude/.claude.json correctly contained "tengu_ccr_bridge": true, but the value was never read because qA() bailed out early.

Settings that caused it

{
  "env": {
    "DISABLE_TELEMETRY": "0",
    "DISABLE_ERROR_REPORTING": "1",
    "CLAUDE_CODE_HIDE_ACCOUNT_INFO": "1"
  }
}

Fix

Removing DISABLE_TELEMETRY from the settings entirely (not setting it to "0", just deleting the key) resolved the issue. /remote-control appeared immediately.

Suggested code fix

Use the same w1() helper for DISABLE_TELEMETRY that's already used for the other env vars in the same function:

// Before (broken):
!!process.env.DISABLE_TELEMETRY

// After (consistent):
w1(process.env.DISABLE_TELEMETRY)

This would make "0" and "false" behave as expected (falsy), matching the behavior of CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, etc.

As a general design concern: telemetry preferences should not gate functional features like Remote-Control. A user opting out of telemetry has no expectation that this would disable unrelated product functionality. These should be independent settings evaluated through separate code paths.

try unset CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC && claude rc

this worked for me

Here is a minimal binary patch that restores 1M context, /remote-control, and /btw when DISABLE_TELEMETRY=1 or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 is set. Tested on v2.1.76, Max 20x, macOS: https://gist.github.com/ahundt/158d498f07a10fec4955a70bf475a20b

Here is a minimal binary patch that restores 1M context, /remote-control, and /btw when DISABLE_TELEMETRY=1 or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 is set. Tested on v2.1.76, Max 20x, macOS: https://gist.github.com/ahundt/158d498f07a10fec4955a70bf475a20b

I encountered the problem of not seeing 1M context model variants in claude on a Max subscription. This occurred in one environment, but not in another suggesting it's some setting that's tripping it up. However, I don't know which setting it is. My tests did not confirm it's one of the settings already mentioned.

Two workarounds that worked:

1. Launch ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-6[1m] claude so that selecting Opus actually selects the 1M context variant.
2. Enable Extra Usage (in claude.ai settings) with any monthly limit (e.g., $1). This makes the 1M variants appear in the /model menu. Although they state that they come with an extra charge, my tests suggest they do not and are in fact included in the Max sub (as expected).

This needs to get fixed. Gating a feature, whether intentional or not, especially on paying accounts by making telemetry mandatory is ridiculous. This also happens with system wide environment variables on Windows.

Additionally, many MCPs have telemetry on by default without notifying the user so turning it off system-wide is the safest way to ensure your "telemetry" data doesn't exit your machine.

This may be another step down the path that Anthropic started down in September 2025.

This is still happening as of today (2026/04/20).
I happened to find it by chance while disabling telemetry.
Not only is rc not available from the command line, it also disappears as an option when searching from the available commands (e.g. with /rem)

OSX, claude code version 2.1.14

This needs to get fixed. Gating a feature, whether intentional or not, especially on paying accounts by making telemetry mandatory is ridiculous

It seems as though Claude Code uses GrowthBook for both feature flags and telemetry, which makes sense during staged rollouts or A/B testing of a new feature. What seems to be missing is the promotion of features out from behind GrowthBook feature flags once they're mature / generally-available. I'm pessimistic that this will ever be addressed by Anthropic.

Same issue still reproduces on v2.1.148, macOS, Claude Max (personal org).

Repro:

• ~/.claude/settings.json had "env": { "DISABLE_TELEMETRY": "1" }
• claude --remote-control → Error: Remote Control is not yet enabled for your account.
• Removed DISABLE_TELEMETRY from settings.json, no other changes → Remote Control launches fine.

The error message is particularly confusing because:

1. It blames account eligibility, not config
2. Nothing in the Remote Control docs mentions telemetry flags as a prerequisite
3. Statsig (used for feature flag eval) and telemetry are conceptually separate to users — they reasonably expect to disable analytics while keeping gated features

+1 to the suggested fix: either evaluate feature flags via a non-telemetry channel, or surface a clear error like Remote Control requires Statsig feature-flag eval; DISABLE_TELEMETRY=1 blocks this. Use CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC instead if you want privacy without breaking gated features.

Ridiculous that I'm paying $200 a month for this and i can't use all the features. Still an issue.

I also have this problem with the latest (2.1.211) release