[BUG] Remote Control 'not yet enabled' on Max 20x — caused by CLAUDE_CODE_ENABLE_TELEMETRY=0 silently blocking GrowthBook fetch

Summary

claude remote-control returns Error: Remote Control is not yet enabled for your account for Max 20x users when CLAUDE_CODE_ENABLE_TELEMETRY=0 is set in ~/.claude/settings.json (under the env block). The error message is misleading — the account is eligible; the GrowthBook feature flag fetch is silently blocked because tengu_ccr_bridge (and several others) are classified as non-essential traffic gated behind telemetry.

Affected versions

• Claude Code 2.1.126 (macOS, Apple Silicon)
• Plan: Max 20x (organizationType: claude_max, organizationRateLimitTier: default_claude_max_20x)

Steps to reproduce

1. ~/.claude/settings.json contains:

``json
{ "env": { "CLAUDE_CODE_ENABLE_TELEMETRY": "0" } }
``

1. Run claude remote-control
2. Observe: Error: Remote Control is not yet enabled for your account.

~/.claude.json shows:

• cachedGrowthBookFeatures: <stale or empty>
• hasAvailableSubscription: null (despite active Max 20x in oauthAccount)

Workaround

Remove CLAUDE_CODE_ENABLE_TELEMETRY from settings.json:

jq 'del(.env.CLAUDE_CODE_ENABLE_TELEMETRY)' ~/.claude/settings.json | sponge ~/.claude/settings.json
claude -p "ping" --model haiku   # triggers re-fetch
claude remote-control            # now connects

After this, cachedGrowthBookFeatures.tengu_ccr_bridge: true populates and Remote Control connects in ~5 seconds.

What's actually wrong

CLAUDE_CODE_ENABLE_TELEMETRY=0 is documented as disabling telemetry, but in practice it also gates the GrowthBook feature-flag fetch (or at least the tengu_ccr_* family). Users who legitimately want to opt out of telemetry are silently locked out of Remote Control with an error message that points them at billing/support instead of the actual cause.

Asks

1. Decouple feature-flag fetch from telemetry opt-out. Feature flags drive product gating, not metrics — they should fetch regardless of CLAUDE_CODE_ENABLE_TELEMETRY.
2. Improve the error. not yet enabled for your account should distinguish "your subscription is ineligible" from "feature-flag cache is empty/stale" from "non-essential traffic disabled by env".
3. Don't regress tengu_ccr_bridge: true for Max accounts. Several reports already exist (#33119, #34528, #35596, #38488). When the flag flips false server-side after working previously, users have no actionable signal.

Happy to share accountUuid privately if helpful for triaging the server-side flag history.