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

[jschneider]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Bug Description

claude remote-control fails with "Error: Remote Control is not yet enabled for your account" when DISABLE_TELEMETRY=1 is set — even on an eligible account.

Steps to Reproduce

1. DISABLE_TELEMETRY=1 claude remote-control
2. Observe: "Error: Remote Control is not yet enabled for your account"
3. claude remote-control (without the variable)
4. Observe: works correctly

Expected Behavior

DISABLE_TELEMETRY should disable analytics/tracking only. It should not affect feature-gate evaluation for Remote Control.

Environment

• Claude Code: 2.1.63
• OS: Linux (Ubuntu)

What Should Happen?

DISABLE_TELEMETRY should disable analytics/tracking only. It should not affect feature-gate evaluation for Remote Control.

Error Messages/Logs

DISABLE_TELEMETRY=1 claude remote-control
Error: Remote Control is not yet enabled for your account.
❯ claude remote-control

·✔︎· Connected

Steps to Reproduce

DISABLE_TELEMETRY=1 claude remote-control
claude remote-control

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.63 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

No response

[github-actions]

Found 1 possible duplicate issue:

1. [Workaround] remote-control "not enabled" error caused by stale Statsig cache when DISABLE_NONESSENTIAL_TRAFFIC was set #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

[jschneider]

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...

[n0x00x]

try unset CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC && claude rc

[jschneider]

"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC" has not been enabled for me.

Therefore, unsetting does not change anything.

[Tuxerino420]

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.

[VashisthaCT]

try unset CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC && claude rc

this worked for me