Remote Control unavailable on Max plan (v2.1.59)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/28816
2. https://github.com/anthropics/claude-code/issues/28817
3. https://github.com/anthropics/claude-code/issues/28501

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

I am also having this issue on the max plan ($200/month)
Claude Code v2.1.59
OS: Windows 11

I have a Team subscription and a Personal Max subscription under the same email address and no matter which plan I log in with I'm gettign 'Remote Control is not yet available on your plan'.

I am also having this issue on the max plan.
Claude Code: v2.1.59
OS: Linux 5.15.196

Same issue — Max plan, macOS, native install v2.1.59.

Error:

Error: Remote Control is not enabled for your account. Contact your administrator.

Diagnosis:

• claude auth status shows authMethod: "oauth_token", apiProvider: "firstParty" — OAuth is correctly configured
• ~/.claude.json has valid oauthAccount with billingType: "stripe_subscription" confirming Max plan
• However, the account has an auto-created organizationUuid (personal org, not Team/Enterprise)
• The server sends tengu_ccr_bridge: false on every startup, overwriting any local override
• CLI displays "Claude API" instead of "Claude Max" (issue #20976)

Root cause: The server appears to classify accounts with any organizationUuid as Team/Enterprise, even when it's the auto-created personal org. Since the docs state Remote Control is "not available on Team or Enterprise plans," this disables the feature for Max subscribers whose accounts have this auto-generated org.

What I've tried (none worked):

• Deleting keychain credentials + oauthAccount and re-logging in (including incognito)
• Clearing cachedGrowthBookFeatures and cachedStatsigGates
• Manually setting tengu_ccr_bridge: true (overwritten on startup)
• There is no option to leave/delete the auto-created personal organization on claude.ai/settings

Environment: macOS Darwin 25.3.0, Claude Code v2.1.59, Max plan (stripe_subscription)

any solution ?

Same issue as reported here.
Claude Code version: 2.1.59
Plan: Max (confirmed via claude auth status)
OS: macOS (Tahoe 26.3.0)

Max plan subscriber experiencing this issue on macOS.

• Claude Code version: 2.1.62 (native install)
• Plan: Max (confirmed via claude auth status — subscriptionType: "max")
• OS: macOS, Ghostty terminal
• Auth method: claude.ai

Have completed the full migration from Homebrew/npm to native installer, re-authenticated, and confirmed correct PATH (~/.local/bin/claude). Still receiving "Remote Control is not yet available on your plan." Would appreciate account enablement if this is being done manually during the staged rollout.

Update — found the root cause identified by @javflocor

Running cat ~/.claude.json | grep -i org shows:

"cachedExtraUsageDisabledReason": "org_level_disabled",
"organizationUuid": "a31c8c50-9535-49f6-a9bc-25cdb4150802",
"organizationName": "bgadoci@gmail.com's Organization",
"organizationRole": "admin"

The org_level_disabled reason combined with the auto-generated personal org is blocking Remote Control despite an active Max subscription. Nothing to fix on the client side — this needs a backend correction.

Environment: macOS, Claude Code v2.1.62 (native install), Max plan (stripe_subscription)

Hitting the same issue

##FIXED##
Go to your .claude directory and find the settings.json file
Clear it and enter the following
{"env": {}}
then logout and log back in

This worked for me. I had some custom settings that were preventing the remote control option from being displayed.

Same issue — Max plan, macOS, native install v2.1.62.

Error:

$ claude remote-control
Error: Remote Control is not yet available on your plan.

Diagnosis:

• claude auth status correctly shows subscriptionType: "max", authMethod: "claude.ai", apiProvider: "firstParty"
• ~/.config/claude/.claude.json reports hasAvailableSubscription: false and cachedExtraUsageDisabledReason: "out_of_credits" despite active Max subscription
• Account has auto-created personal organizationUuid (michaelschleiss87@gmail.com's Organization)
• Subscription status fields are not refreshed by claude auth logout / claude auth login — server re-populates incorrect values on every startup

What I've tried (none worked):

• Full logout/login cycle (claude auth logout → claude auth login)
• Clearing cachedStatsigGates, cachedGrowthBookFeatures, oauthAccount, and all subscription cache fields
• Clearing Statsig cache files (~/.config/claude/statsig/statsig.cached.evaluations.* etc.)
• Manually setting hasAvailableSubscription: true (overwritten on startup)
• Removing organizationUuid from cached oauthAccount (server re-fetches)
• Resetting settings.json to {"env": {}}

Environment: macOS Darwin 25.2.0, Claude Code v2.1.62 (native install), Max plan (stripe_subscription)

So guys, did the downgrade to Claude version 2.1.55 and them upgraded to 2.1.62 and ake it happen. took more than a day to discover.

Follow-up — still blocked on v2.1.63

Issue persists on latest version. New data since my original comment:

• cachedExtraUsageDisabledReason: "org_level_disabled" — server explicitly applying org-level policy to a personal subscription
• hasExtraUsageEnabled: false — despite active Max billing via Stripe
• Version cycling (downgrade → upgrade) has no effect; tengu_ccr_bridge is server-assigned on startup
• Resetting settings.json to {"env": {}} does not affect the server-side flag

Multiple duplicate issues and confirmations across this thread all trace to the same root cause. As a workaround, I've been using Happy with Claude Code, and separately OpenClaw to get remote access to my local sessions — but that shouldn't be necessary on a Max plan :S

Is there a timeline for a backend fix?

Any update? I upgraded specifically for this feature.

Hi there! I was running into a similar issue with my 20x Max subscription and nothing seemed to work for me. Then I noticed that the output of claude auth status did not change, even after running claude code logout.

So then I did the following:

• Run claude auth status to check your login status. For me, it only showed: { loggedIn: true, authMethod: OAuth, apiProvider: firstParty}
• Remove CLAUDE_CODE_OAUTH_TOKEN from your .zshrc if set (I had previously set this myself)
• Open up a new shell (or run unset CLAUDE_CODE_OAUTH_TOKEN)
• Remove all entries related to claude from the macos keychain
• Go to claude.ai -> settings -> claude code -> revoke ALL authorization tokens
• Run claude and try to send a message to confirm the logout
• Open Claude Desktop to confirm logout
• Uninstall claude code (on macos you can run rm -f ~/.local/bin/claude ~/.local/share/claude)
• Restart my machine (just to be sure)
• Open Claude Desktop and log back in
• Reinstall Claude Code (curl -fsSL https://claude.ai/install.sh | bash)
• Run claude auth status to verify you're still logged out (loggedIn should be false)
• Run claude code login to log back in
• Rerun claude code status to confirm the login. You should now see a different output from the first time you ran this command. For me, it now showed my email, orgId, orgName and subscriptionType in addition to the values shown in the first step. Most notably, it now has authMethod set to claude.ai instead of OAuth.

After this, everything seems to work for me.

Hope this helps!

Hi! @karimStekelenburg suggestion works! Thanks a lot!

Resolved — Root Cause: Stale CLAUDE_CODE_OAUTH_TOKEN env var

The issue was a stale CLAUDE_CODE_OAUTH_TOKEN environment variable exported in ~/.zshrc. This forced authMethod: "oauth_token" instead of authMethod: "claude.ai", which doesn't carry
the subscription/org context needed for Remote Control.

Steps that fixed it:

1. Commented out export CLAUDE_CODE_OAUTH_TOKEN=... in ~/.zshrc
2. Revoked old authorization tokens at claude.ai → Settings → Claude Code
3. Opened a new terminal (critical — the running shell/process caches the old env var in memory)
4. Re-authenticated with claude auth login (browser-based OAuth flow)
5. Verified claude auth status now shows:

• authMethod: "claude.ai" (not "oauth_token")
• apiProvider: "firstParty"

1. Confirmed claude rc / Remote Control works

Key insight: If you previously set CLAUDE_CODE_OAUTH_TOKEN (e.g., for API access or an earlier auth method), it takes priority over the browser-based auth and silently breaks features
like Remote Control that require the full claude.ai auth context. The env var doesn't carry org/subscription info, so the server rejects Remote Control requests.

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.