[BUG] Remote Control: "is not yet enabled for your account" persists for Max user across all documented troubleshooting steps

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?

Running claude remote-control (or /remote-control from within an interactive session) always fails with:

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

The error has persisted for months across multiple CLI versions, reinstalls, and account state changes. I cannot connect Claude Code to the mobile app or claude.ai/code from any device.

The eligibility check is rejected before any handshake or network activity — --verbose produces no additional output beyond the error line, indicating the rejection happens client-side based on a cached server response.

I have ruled out every documented troubleshooting cause (see "Additional Information" below for the full diagnostic table and the smoking-gun s1mAccessCache: hasAccess: false entry that re-populates from the server even after manual deletion).

What Should Happen?

claude remote-control should start a Remote Control session, print a session URL and QR code, and make the session visible in the Claude mobile app's "Code" tab. From there, the session should be controllable from the mobile app or from claude.ai/code.

This is the documented behavior at https://code.claude.com/docs/en/remote-control for Pro/Max accounts on Claude Code 2.1.51+.

Error Messages/Logs

PS C:\Users\sd_ig> claude remote-control
Error: Remote Control is not yet enabled for your account.

PS C:\Users\sd_ig> claude remote-control --verbose
Error: Remote Control is not yet enabled for your account.

# Exit code: 1
# Note: --verbose produces no additional output beyond the error line above.
# The rejection happens immediately, before any handshake or network activity.

Steps to Reproduce

Prerequisites: A Claude Max account (claude_max subscription) authenticated to Claude Code via claude.ai OAuth, on Claude Code 2.1.51 or higher.

1. Open PowerShell (or any terminal) on Windows 11.
2. Verify auth state:

``
claude auth status
`
Confirms: loggedIn: true, apiProvider: firstParty, subscriptionType: max`.

1. Verify version:

``
claude --version
`
Returns 2.1.150 (Claude Code)`.

1. Confirm no conflicting environment variables are set in any scope (Process / User / Machine):

• ANTHROPIC_API_KEY — empty
• CLAUDE_CODE_OAUTH_TOKEN — empty
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC — empty
• DISABLE_TELEMETRY — empty (was previously "1", removed and terminal restarted)
• CLAUDE_CODE_USE_BEDROCK / USE_VERTEX / USE_FOUNDRY — all empty

1. Run:

``
claude remote-control --verbose
``

1. Observe: immediate failure with Error: Remote Control is not yet enabled for your account. and exit code 1.

Result: Bug reproduces 100% of the time. Has been reproducing for months across multiple Claude Code versions, a full reinstall, OAuth /logout + /login, and a mobile-app re-login. Issue is not intermittent.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.150 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Account Context

• Email: d***@gmail.com (masked)
• orgId: 24bc7e15-ae4f-4598-b775-1df5db38b67c
• accountUuid: d393c54b-52a4-4c69-ba87-829b7470603a
• organizationType: claude_max
• organizationRateLimitTier: default_claude_max_5x
• Shell: PowerShell 7.6.1 on Windows 11

The orgId and accountUuid are included so Anthropic can resolve the case directly — these are opaque identifiers, not secrets.

Troubleshooting Steps Already Completed

Per the official troubleshooting guide at https://code.claude.com/docs/en/remote-control#troubleshooting, I have ruled out every documented cause:

| Documented cause | Verification | Result |
|---|---|---|
| ANTHROPIC_API_KEY set | [Environment]::GetEnvironmentVariable("ANTHROPIC_API_KEY", scope) for Process, User, Machine | Empty in all 3 scopes |
| CLAUDE_CODE_OAUTH_TOKEN set (long-lived / inference-only token) | Same check, 3 scopes | Empty in all 3 scopes |
| CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC set | Same check | Empty |
| DISABLE_TELEMETRY set | Found set to "1" in User scope. Removed via SetEnvironmentVariable(..., $null, "User"). Terminal restarted. Verified $env:DISABLE_TELEMETRY is now empty | Removed, error persists |
| CLAUDE_CODE_USE_BEDROCK / USE_VERTEX / USE_FOUNDRY set | Same check | All empty |
| Stale cached account info | Ran /logout then /login via claude.ai OAuth. Confirmed claude auth status shows fresh subscriptionType: max, apiProvider: firstParty | Refreshed, error persists |
| Not on Pro/Max | Confirmed Max via auth status and via claude.ai subscription page | N/A — Max is active |
| Team/Enterprise admin not enabling toggle | Account is personal Max, not Team/Enterprise. No managed-settings.json present at C:\ProgramData\ClaudeCode\ | N/A |
| Managed settings disableRemoteControl key | Checked ~/.claude/settings.json, %APPDATA%\Claude\settings.json, %LOCALAPPDATA%\Claude\settings.json, %ProgramData%\ClaudeCode\managed-settings.json | No disableRemoteControl key found anywhere |
| Network/proxy blocking | Test-NetConnection api.anthropic.com -Port 443 succeeds. No HTTP(S)_PROXY env vars. Cloudflare WARP not installed (only an unrelated outbound-only cloudflared tunnel) | Network clean |
| Version below 2.1.51 | claude --version returns 2.1.150 | Above minimum |
| Mobile app re-login | Completed | No change |

Smoking Gun — Local Cache State

C:\Users\sd_ig\.claude.json contains the following cache entry:

"s1mAccessCache": {
  "24bc7e15-ae4f-4598-b775-1df5db38b67c": {
    "hasAccess": false,
    "hasAccessNotAsDefault": false,
    "timestamp": 1779561568113
  }
}

The client is caching that my org does not have access to Remote Control. To test whether this was stale local state, I:

1. Backed up .claude.json
2. Deleted the entire s1mAccessCache block
3. Validated JSON
4. Restarted Claude Code

Result: the cache re-populated from the server with hasAccess: false for my orgId. This confirms the rejection is server-side, not stale local cache.

For context, other relevant flags in the same file are correctly set:

• "penguinModeOrgEnabled": true (Max recognized)
• "oauthAccount.organizationType": "claude_max" ✓
• "oauthAccount.hasExtraUsageEnabled": true ✓
• "tengu_ccr_bridge": true (bridge feature enabled at config level)
• "tengu_bridge_repl_v2": true ✓
• "tengu_ccr_bridge_multi_session": true ✓

So the org has Max, the bridge infrastructure flags are on, but the per-account s1mAccess flag is off.

Hypothesis

My Max account was not included in the Remote Control rollout server-side, or the s1mAccess flag was never flipped to true for orgId 24bc7e15-ae4f-4598-b775-1df5db38b67c despite Max being active. Either way, this requires an internal server-side action — there is no client-side or user-side fix.

Request

Please flip the s1mAccess / Remote Control eligibility flag for orgId 24bc7e15-ae4f-4598-b775-1df5db38b67c (account UUID d393c54b-52a4-4c69-ba87-829b7470603a) so I can use the feature my Max subscription includes.

If there is a broader rollout policy issue, I'd appreciate confirmation of what determines per-account eligibility and an ETA for Max users still excluded.

Happy to provide any additional diagnostic output. I've already spent multiple hours ruling out every documented client-side cause.