[BUG] Desktop: Remote Control never auto-enables on individual (Pro/Max) plans — rcAutoEnable returns source=settings_unavailable on every session because the managed-settings gate is ordered before the personal-plan short-circuit

Summary

On an individual (Pro/Max) plan with no Team/Enterprise organization, Claude Desktop's Remote Control auto-enable has been dead for 3 days. The rcAutoEnable resolver runs on every new session and returns:

[rcAutoEnable] managed settings not yet authoritative for this org; not connecting this pass
[rcAutoEnable] verdict: enable=false source=settings_unavailable

115 consecutive failures, 0 successes, since 2026-08-22 08:05:50. 47 of them today alone.

The "Connect new sessions to Remote Control" toggle in Settings → Claude Code is ON and has been the whole time. It has no effect: the resolver never reaches the step that reads it.

This is not the known isFirstTurn family of bugs (#87777, #85435, #80969, #82140, #78730, #78667). In all of those the resolver either doesn't fire at all, or fires and returns enable=true source=explicit_pref. Here it fires reliably on every session creation and actively refuses. settings_unavailable does not appear in any existing issue.

Environment

| | |
|---|---|
| Claude Desktop | 1.34493.1 (macOS, Apple Silicon) |
| Bundled CLI | 2.1.237 |
| CLI on PATH | 2.1.241 |
| Plan | Individual (Pro/Max) — claude.ai/admin-settings/claude-code returns "You don't have access to organization settings — Organization settings are available on Claude Team and Enterprise plans." |
| MDM / managed settings | None. No /Library/Managed Preferences/ entry, no /Library/Application Support/ClaudeCode/, no remoteControl* key in ~/.claude/settings.json |

Timeline

Correlates exactly with the 1.34493.0 update.

| Date | App version | rcAutoEnable verdict |
|---|---|---|
| 08-14 → 08-19 07:03 | 1.30096.x / 1.32352.x | enable=true source=explicit_pref (working, ~25 successes) |
| 08-19 07:03:34 | 1.32352.1 | last success ever |
| 08-19 10:58 | 1.32885.1 | (no verdicts logged in this window) |
| 08-20 17:09 | 1.34493.0 | first [TranscriptLease] Server-managed settings unavailable; skipping this pass |
| 08-22 08:05:50 | 1.34493.1 | first source=settings_unavailable |
| 08-22 → 08-24 | 1.34493.1 | 115 consecutive settings_unavailable, 0 successes |

Verdict counts from the current main.log:

  1  2026-08-19  source=explicit_pref
 34  2026-08-22  source=settings_unavailable
 34  2026-08-23  source=settings_unavailable
 47  2026-08-24  source=settings_unavailable

The app has been restarted 5+ times across this window. It does not recover.

Note that [TranscriptLease] Server-managed settings unavailable; skipping this pass fires from the same underlying read, starting at the first launch of 1.34493.0 — so whatever regressed is not Remote-Control-specific, it's the managed-settings read itself never becoming authoritative for a personal account.

Root cause

From the resolver in the bundled app.asar, the decision order is:

1. feature-gate check → third_party / feature_gate_off
2. auth check → no_auth
3. managed-settings check → settings_unavailable ← always returns here
4. read the user's "connect new sessions" preference → explicit_pref
5. subscription/policy check → contains new Set(['pro','max']), which short-circuits with {ok: true, policyLimits: null} and never queries org policy

Step 5 is where the code correctly recognises that an individual plan has no organization policy to consult. But step 3 already returned. A Pro/Max account can never reach its own short-circuit.

Step 3 fails closed: if the managed-settings state is null or not authoritative, it logs "managed settings not yet authoritative for this org" and returns settings_unavailable. For an account with no organization there is no org policy that will ever arrive, so this is permanent, not transient — which matches 115/115 failures across 5 app restarts and 3 days.

There is no user-visible surface for this. No error, no notification, no state shown in the UI; the Settings toggle keeps reading ON. The only evidence is main.log.

The CLI is unaffected

The gate lives only in Desktop's own code:

| binary | rcAutoEnable | settings_unavailable | managed settings not yet authoritative | org_denied / policy_unavailable |
|---|---|---|---|---|
| Desktop app.asar | present | present | present | present |
| CLI 2.1.237 (bundled) | absent | absent | absent | present |
| CLI 2.1.241 (PATH) | absent | absent | absent | present |

claude --resume <id> + /remote-control in a terminal connects immediately on the same machine, same account, same network. Only Desktop-hosted sessions are affected.

Impact

Remote Control is completely unusable from Claude Desktop on an individual plan. Every session started in the app is invisible to the phone and to claude.ai/code. For anyone who develops in Desktop, the feature is gone with no error message and no setting they can change — the admin page the gate implicitly points at is not available on their plan.

Suggested fix

• Evaluate the Pro/Max short-circuit (step 5) before the managed-settings gate (step 3), or skip step 3 entirely when the account has no organization.
• Treat "no organization" as a definitive authoritative answer rather than "not yet authoritative", so the check terminates instead of failing closed forever.
• Surface the refusal in the UI. A permanently-disabled feature whose toggle still reads ON, with the only trace in a log file, costs users days.

Workaround

Run the session from a terminal (claude --resume <id> then /remote-control, or claude remote-control in server mode under tmux). The CLI does not have the gate.

Reproduction

1. Individual (Pro/Max) plan, no Team/Enterprise org.
2. Claude Desktop 1.34493.1, Settings → Claude Code → Connect new sessions to Remote Control ON.
3. Start any new session in the app.
4. grep "rcAutoEnable" ~/Library/Logs/Claude/main.log | tail -5

Expected: verdict: enable=true source=explicit_pref, followed by Remote control enabled: https://claude.ai/code/session_...

Actual: managed settings not yet authoritative for this org; not connecting this pass → verdict: enable=false source=settings_unavailable, and nothing else.