Remote Control not enabled on Max plan account

[Caylub]

TL;DR — Resolved

Cause: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 in my shell profile silently disables all GrowthBook feature flag evaluation, hiding /remote-control, /rc, /btw, and other gated commands.

Fix: Remove it from your shell profile and start a new session. Also check for DISABLE_TELEMETRY — same effect. See root cause analysis comment.

---

Problem

Running claude remote-control returns:

Error: Remote Control is not yet enabled for your account.

20x MAX Billing From My Account

The /remote-control slash command inside an active session returns "Unknown skill: remote-control".

Environment

• Claude Code version: 2.1.72 (latest)
• Install method: native
• Auth method: OAuth (claude.ai)
• Plan: Max (stripe_subscription)
• OS: Pop!_OS (Linux 6.17.9)
• Node.js: system default

Billing Confirmation

Active Max plan (20x), renewing Apr 8, 2026 — confirmed at claude.ai/settings/billing.

Troubleshooting completed

1. Full /logout + /login cycle — no change
2. Verified no conflicting env vars (CLAUDE_CODE_OAUTH_TOKEN, ANTHROPIC_API_KEY are unset)
3. Confirmed ~/.claude.json shows billingType: "stripe_subscription" but hasAvailableSubscription: false
4. Manually setting hasAvailableSubscription: true in ~/.claude.json does not help — server-side validation rejects it
5. On latest CLI version (2.1.72)

Observed

~/.claude.json contains:

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

The login flow does not refresh hasAvailableSubscription to true despite an active Max subscription.

Related issues

• Remote Control unavailable on Max plan - 'not yet enabled for your account' #30756
• Remote Control not enabled on Max plan: 'Remote Control is not yet enabled for your account' #31606
• Remote Control not enabled for Max plan account #30242

Expected

Remote Control should be available for Max plan subscribers per https://code.claude.com/docs/en/remote-control

[github-actions]

Found 3 possible duplicate issues:

1. Remote Control unavailable on Max plan - 'not yet enabled for your account' #30756
2. Remote Control not enabled on Max plan: 'Remote Control is not yet enabled for your account' #31606
3. Remote Control not enabled for Max plan account #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

[Caylub]

Additional Evidence

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

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.

[Caylub]

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)

[MidnightDarling]

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.

[sisyphusSmiling]

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

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

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

5. started claude again and had /rc available.

[Caylub]

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

[samson-bakos]

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

[pannous]

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