[BUG] /remote-control silently hidden when DISABLE_TELEMETRY or DO_NOT_TRACK is set — gate blocks flag reads even when tengu_ccr_bridge is cached true (v2.1.199)

Preflight Checklist

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

What's Wrong?

In interactive mode, the /remote-control (alias /rc) slash command is silently hidden from the command menu — no error, no diagnostic — whenever DISABLE_TELEMETRY=1 or DO_NOT_TRACK=1 is set (either alone is sufficient, including via the env block of settings.json).

This is related to #29580 (which covers the claude remote-control CLI subcommand erroring with DISABLE_TELEMETRY), but this report adds three findings from tracing the gate logic in the v2.1.199 binary:

1. DO_NOT_TRACK is also in the gate list, not just DISABLE_TELEMETRY / CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. DO_NOT_TRACK is a widely-used cross-tool privacy convention; users setting it globally will lose Remote Control with no indication why.
2. Interactive mode fails silently. The command object is registered with isEnabled: <gate>, isHidden: !<gate>(), so an ineligible session hides the command entirely instead of surfacing the (already misleading) "not yet enabled" error the CLI subcommand shows.
3. The vars block feature-flag _reads_, not just fetches. The gate chain is roughly: eligibility requires ot("tengu_ccr_bridge", false); ot() short-circuits to the default (false) whenever telemetry opt-out is detected — _without ever consulting the cache_. In my case cachedGrowthBookFeatures.tengu_ccr_bridge in ~/.claude.json was cached true (account is in the rollout, fetched successfully the same day), yet the command stayed hidden because the read path was gated off.

Finding #3 makes this very hard to debug and likely explains reports like #43574, where removing the vars "didn't work" — if _any one_ of the three vars remains set anywhere (settings.json env block, shell profile, exported in the current shell), the flag read is still blocked. During my own debugging, removing only DISABLE_TELEMETRY while DO_NOT_TRACK stayed set made the fix appear ineffective and sent the investigation down dead ends (workspace trust, statsig cache staleness, auth refresh) for several hours.

What Should Happen?

• Telemetry/privacy opt-out vars should disable analytics _reporting_, not feature-gate evaluation. At minimum, cached flag values that were legitimately fetched should still be readable.
• If the coupling is intentional, the interactive command should not be silently hidden. Show it with a disabled state or an actionable message naming the offending variable — the binary already contains a function that maps each gate var to an error string, but the slash-command path never uses it.
• /doctor should call out this condition explicitly (related: #73007).

Steps to Reproduce

1. On an account eligible for Remote Control (verify /remote-control appears normally).
2. Add "DO_NOT_TRACK": "1" (or "DISABLE_TELEMETRY": "1") to the env block of ~/.claude/settings.json.
3. Start a fresh interactive claude session.
4. Type /remote-control or /rc — the command is not in the menu and typing it says it isn't available in this environment. No error or hint is shown.
5. Remove the variable, start a fresh session — the command reappears immediately (no re-auth needed, since the flag was cached all along).

Environment

• Claude Code: 2.1.199
• OS: macOS (Darwin 25.5.0)
• Auth: claude.ai subscription (OAuth), first-party API

Is this a regression?

Unknown — the silent-hide behavior exists at least as of 2.1.199; #29580 reports the CLI-subcommand variant as never having worked (2.1.63).