Remote Control not enabled on Max plan account

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/30756
2. https://github.com/anthropics/claude-code/issues/31606
3. https://github.com/anthropics/claude-code/issues/30242

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

Additional Evidence

Confirmed active Max plan (20x) on claude.ai/settings/billing — subscription renews Apr 8, 2026:

!Max plan billing confirmation

Despite this, ~/.claude.json persists with:

"hasAvailableSubscription": false,
"oauthAccount": {
    "hasExtraUsageEnabled": false,
    "billingType": "stripe_subscription"
}

The OAuth login flow is not refreshing the subscription status flag.

Additional Diagnostics

claude auth status correctly identifies the subscription:

{
  "loggedIn": true,
  "authMethod": "claude.ai",
  "apiProvider": "firstParty",
  "subscriptionType": "max"
}

However, the cached account metadata in ~/.claude.json (populated server-side during OAuth) contains contradictory values:

"hasAvailableSubscription": false,
"cachedExtraUsageDisabledReason": "org_level_disabled",
"penguinModeOrgEnabled": false,
"oauthAccount": {
    "hasExtraUsageEnabled": false,
    "billingType": "stripe_subscription"
}

The issue

Two different server endpoints return conflicting data for the same account:

1. Auth status endpoint → correctly returns subscriptionType: max
2. OAuth account metadata endpoint → returns hasAvailableSubscription: false and cachedExtraUsageDisabledReason: "org_level_disabled"

The Remote Control feature gate appears to check the cached metadata rather than the auth status, so it sees hasAvailableSubscription: false and blocks access.

cachedExtraUsageDisabledReason: "org_level_disabled" is particularly suspicious for a personal Max account with no organization hierarchy — there is no org-level admin to disable anything.

Editing these values locally has no effect — they are overwritten on each login/session start with the same incorrect server response.

Steps already attempted

• Multiple full logout/login cycles
• Revoking all Claude Code authorization tokens via claude.ai settings
• Unsetting CLAUDE_CODE_OAUTH_TOKEN and ANTHROPIC_API_KEY env vars
• Manually editing ~/.claude.json (overwritten by server)
• Confirmed authMethod: claude.ai (not OAuth)
• Confirmed active Max 20x plan on claude.ai/settings/billing (renews Apr 8, 2026)

Same issue here. Max 20x plan ($200/month, annual billing at $2,400/year). CLI version 2.1.72 on macOS.

$ claude remote-control
Error: Remote Control is not yet enabled for your account.

claude auth logout && claude auth login does not resolve it. This appears to be a server-side feature gate issue rather than a client-side problem.

Would appreciate a fix or at least a timeline — paying the highest individual tier and not getting access to an officially supported feature is frustrating.

Had the same issue even after exiting, updating and starting a new session on macOS 26.3.

The following resolved it for me and I now have /rc accessible:

1. /logout
2. /login
3. /rc still not available
4. from terminal, ran claude update which output the following

```sh
Current version: 2.1.74
Checking for updates to latest version...

Claude is managed by Homebrew.
Claude is up to date!
```

1. started claude again and had /rc available.

@sisyphusSmiling No luck for me trying what you did

• updated to 2.1.74
• /logout
• /login

Still no /remote-control (claude remote-control also didn't work), /rc, /btw, (none of the new stuff...)

+1 on this issue. Max 20x plan, macOS (Darwin 24.6.0, arm64), Claude Code
v2.1.74 (native installer).

~/.claude.json shows:
"claudeMaxTier": "20x",
"billingType": "stripe_subscription",
"hasAvailableSubscription": false,
"hasAvailableMaxSubscription": false,
"tengu_ccr_bridge": false,

Tried:

• Clearing all Statsig cache files in ~/.claude/statsig/ and stats-cache.json
• claude auth logout → claude auth login (full re-auth cycle)
• Updating from v2.1.68 to v2.1.74
• Unsetting ANTHROPIC_API_KEY / ANTHROPIC_KEY env vars before auth + rc
• Fresh browser login (not session reuse)

None of these resolve it. tengu_ccr_bridge consistently returns false
server-side despite active Max subscription.

for me unset CLAUDE_CODE_OAUTH_TOKEN worked but that's probably pretty specific because I added that manually to my .bashrc once

Root Cause Found — Fix Verified

TL;DR

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 in my ~/.zshrc was silently disabling ALL GrowthBook feature flag evaluation, causing every feature-gated command (/btw, /remote-control, /rc) to be unavailable. Removing the env var and opening a new session fixed all commands.

Root Cause Analysis

Through binary analysis of Claude Code v2.1.74, I traced the full feature flag evaluation chain:

Command registration:

• /btw: isEnabled: () => s6H() → XA("tengu_marble_whisper2", false)
• /remote-control (alias /rc): isEnabled: D48 → aQ() → XA("tengu_ccr_bridge", false)

Feature flag function XA(flagName, defaultValue):

function XA(H, $) {
  let A = urH();                              // live GrowthBook overrides (always null at runtime)
  if (A && H in A) return A[H];
  if (!Cl()) return $;                        // ← CRITICAL: "not logged in" → return default (false)
  // ... telemetry tracking ...
  let L = O$().cachedGrowthBookFeatures?.[H]; // read from ~/.claude.json
  return L !== void 0 ? L : $;
}

The "login" check Cl() — where it breaks:

function Cl() { return BTH() }
function BTH() { return !UE() }
function UE() {
  return tH(process.env.CLAUDE_CODE_USE_BEDROCK) ||
         tH(process.env.CLAUDE_CODE_USE_VERTEX) ||
         tH(process.env.CLAUDE_CODE_USE_FOUNDRY) ||
         !!process.env.DISABLE_TELEMETRY ||
         !!process.env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC  // ← THIS
}

When CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set to any truthy value, UE() returns true, Cl() returns false, and XA() returns the default value (false) without ever reading the cached GrowthBook features from ~/.claude.json. This silently disables ALL feature-gated functionality.

Why I had this env var

I had export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 in my ~/.zshrc because I'm not a fan of opt-out telemetry and assumed this env var would disable unwanted telemetry traffic. The name strongly suggests it only controls telemetry/analytics, but it's actually used as a proxy for "is this a real authenticated session" in UE(), which gates all feature flag evaluation.

The Fix

1. Remove export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 from your shell profile (.zshrc, .bashrc, etc.)
2. Also check for DISABLE_TELEMETRY — it has the same effect
3. Start a new Claude Code session

Design Issue (for maintainers)

This is a footgun worth addressing:

1. Misleading name — CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC implies telemetry/analytics only, but it disables all feature flag evaluation
2. Set by Claude Code itself — Claude Code exports this for its subprocesses, so users may encounter it (e.g. in env output) and add it to their profile for privacy
3. Silent failure — Feature-gated commands simply don't appear. No warning, no error, no diagnostic output. Users have no way to know why commands are missing
4. DISABLE_TELEMETRY (a generic, widely-used env var from other tools) has the same effect

Suggestions:

• Separate telemetry suppression from feature flag evaluation
• Log a warning when feature-gated commands are disabled due to env vars
• Document the full scope of this env var's side effects

for me unset CLAUDE_CODE_OAUTH_TOKEN worked but that's probably pretty specific because I added that manually to my .bashrc once

Not as specific as you think! That fixed it for me.

I had done the same, I had a pre-rollout OAuth token in my zshrc for Agents SDK stuff.

I aliased unsetting the key + claude remote-control to claude-rc and it works for me now. Probably also works to update the token but was in a hurry.

I found the root cause for my account. My ~/.claude.json shows hasAvailableSubscription: false but my billingType is google_play_subscription. It seems the CLI auth server fails to sync entitlements for users who subscribed via mobile app stores (Google Play) instead of the web interface.

+1 — Max Plan, Windows 11, tengu_ccr_bridge: false

Environment:

• Claude Code v2.1.81 (also tested v2.1.78)
• Windows 11 (Git Bash)
• Auth: OAuth token, firstParty (claude auth status → loggedIn: true, authMethod: "oauth_token", apiProvider: "firstParty")
• Plan: Max (stripe_subscription, subscribed since 2026-01-30)

Diagnostics:

• ~/.claude.json shows billingType: "stripe_subscription" ✅
• cachedGrowthBookFeatures → tengu_ccr_bridge: false ❌
• tengu_ccr_bridge_multi_session: false ❌
• No DISABLE_TELEMETRY or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC env vars set
• Cleared cachedGrowthBookFeatures from ~/.claude.json and retried — server re-evaluates and returns false again

Note: CLAUDE_CODE_OAUTH_TOKEN IS present in the shell environment (appears to be injected by the Claude Desktop app when spawning Code sessions, not set in any profile file). Per @samson-bakos's comment above, this may be interfering with feature flag evaluation. However, I cannot unset it from within a Desktop-spawned session to test.

Attempted fixes (all failed):

1. Updated to v2.1.81
2. Cleared GrowthBook feature cache
3. Verified OAuth login and subscription status

This appears to be a server-side evaluation issue — the GrowthBook flag returns false despite valid Max subscription.

I appear to be suffering from this same problem. I am using CLAUDE_CODE_OAUTH_TOKEN explicitly on a VM I run Claude code on to isolate it from my desktop, and I cannot enable --rc in this mode.

Claude Code v2.1.81, Debian/Linux.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.