[BUG] Desktop 2.9939.2 (Windows Store): mobile "New session" picker offers only Cloud; this computer never listed — Remote Control serving section hidden, serve gate 1183214304 resolves to defaultValue=false

Status Open
Reported on v2.1.281
Maintainer reply None cached
Activity 2 comments · opened Sep 26, 2026

Preflight Checklist

  • [x] I have searched existing issues. Related but different: #90769 (picker shows dead servers as live), #91841 (self-hosted environments for Pro/Max), #84929 (sessions never appear on claude.ai/code).
  • [x] Single bug report.

What's wrong

On the Claude mobile app, New session → environment picker offers only "Cloud". This Windows computer, which has the Claude desktop app open and signed in with the same account, is never offered as a place to start a session. The user reports this worked before; it stopped after the desktop app auto-updated on 2026-09-23 and 2026-09-25.

Remote Control for existing sessions is unaffected: Code-tab sessions register with remoteControlState: "on", [remote-control] bridge_state: "connected", and the phone can open and steer them. Only creating a new session on this computer from another device is impossible.

What I found (desktop side)

  1. The desktop app's Remote Control serving controller never starts on this machine:
  • %LOCALAPPDATA%\Claude\Logs\ contains main.log, claude.ai-web.log, mcp.log, ssh.log, … but no rc-serve log file has ever been created (the controller uses a dedicated logger with prefix rc-serve).
  • %APPDATA%\Claude\remote-control-state.json does not exist.
  • main.log has zero [rc-serve] lines across the retained logs (2026-08-21 → 2026-09-26).
  1. Settings → Claude Code shows no Remote Control serving section (no "Use this computer from your phone and claude.ai?" / folder list). In the bundle, the section is hidden when the status reason is gate_off or third_party.
  2. The feature cache %APPDATA%\Claude\fcache (from /api/desktop/features, fetched 2026-09-26 09:23 +07, 381 features, mode 1p) resolves the gates the serving controller depends on as:
  • 1183214304 (serve gate, isServeGateOn) → on: false, value: false, source: "defaultValue"
  • 3764441751 (accept gate, isAcceptGateOn) → on: true
  • 1410651677 (serving config: folderLimit: 6, rankFoldersByUsage, watchSessions, …) → on: true, source: "force"
  • 30891128 → on: false, source: "defaultValue"

So the serve gate is off because no rule matched this account (defaultValue), not because of anything the user changed.

  1. Everything else in the eligibility chain looks healthy:
  • [rcAutoEnable] verdict: enable=true source=explicit_pref on every session since 2026-09-19 (before that enable=false source=gb_default).
  • Preferences: ccRemoteControlDefaultEnabled: true, keepAwakeEnabled: true, coworkHipaaRestricted: false, no managed/org policy, bypassPermissionsGateByAccount: false.
  • [my-access] refetches succeed; no auth_stale / session_stale_relogin since 2026-09-17 (which recovered on its own).
  • Windows notifications for Claude_pzs8sxrjxfjjc!Claude are enabled (relevant to the "default-on" notification flow); OS sleep timeout is 0 (never).
  1. Legacy path: the sessions-bridge still registers its environment on every launch (POST /v1/environments/bridge (reconnect=env_…)) and reconnects one persisted cse_… session, but no new session work has arrived through it since at least 2026-08-21. coworkLegacyRootGrantsPruned: true and an older remoteSessionFolderGrants entry (2026-09-10) show the previous "cloud session uses a folder on this computer" flow was in use before the update.

Steps to reproduce

  1. Windows 11, Claude desktop (Microsoft Store build) 2.9939.2, signed in with an individual claude.ai subscription; open the Code tab, any session.
  2. On the Claude mobile app with the same account, tap New session and open the environment picker.
  3. Only "Cloud" is offered. Open desktop Settings → Claude Code: there is no Remote Control serving section to turn on.

Expected

Either this computer is offered in the picker (serve gate enabled for individual accounts), or the app tells the user why it is not (e.g. "Starting sessions on this computer from other devices isn't available for your account yet") instead of silently hiding the section. A release note for the behaviour change would also have avoided a long investigation.

Questions

  • Is the serving gate (1183214304) a staged rollout or plan-gated (individual Pro/Max)? If it can be enabled per account, please enable it for the reporting account.
  • If the previous flow was intentionally removed for individual accounts, is claude remote-control (CLI server) the intended way for them to expose a folder to the mobile app in the meantime?

Environment

  • OS: Windows 11 Pro 10.0.22631
  • Claude desktop: 2.9939.2.0 (MSIX, C:\Program Files\WindowsApps\Claude_2.9939.2.0_x64__pzs8sxrjxfjjc); AppX deployment log shows updates 2.2553.1 → 2.7032.0 on 2026-09-23 and → 2.9939.2 on 2026-09-25
  • Bundled Claude Code: 2.1.281 (2.1.280 installed 2026-09-23, 2.1.281 on 2026-09-25)
  • Account: individual claude.ai subscription (1p), org admin; no HIPAA/managed policy
  • Mobile: Claude app on Android

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗