[Bug] Desktop-hosted sessions never register with Remote Control despite remoteControlAtStartup + the Desktop toggle both being on

Summary

With remoteControlAtStartup: true and Desktop → Settings → Claude Code → Enable remote control by default switched on, sessions hosted by the Desktop app never register a Remote Control session. They never appear in the Code list on the mobile app or at claude.ai/code.

Server mode (claude remote-control) on the same machine, same account, same settings file works perfectly and has done for days. So this is specific to Desktop-hosted sessions, not to eligibility, auth, or network.

Environment

• Claude Code 2.1.221 (the ~/.claude/remote/ccd-cli/ build the Desktop app spawns)
• Claude Desktop, Windows x64 (Microsoft Store / MSIX package), sessions executing in WSL2 Ubuntu
• claude.ai Max subscription, signed in via claude.ai OAuth (not an API key)
• CLAUDE_CODE_ENTRYPOINT=claude-desktop

Expected

Each Desktop-hosted session registers its own Remote Control session and shows up under Code with a computer icon, per the "Enable Remote Control for all sessions" docs.

Actual

No Desktop session has ever registered. Only server-mode sessions do.

Evidence

The clearest signal is the per-session remote-sync marker. Across the whole machine, over several days and dozens of Desktop sessions:

$ find ~/.claude/projects -name "*.ccr-tip.json"

returns only files belonging to server-mode sessions. Not one Desktop-hosted session has produced one, including sessions started well after the setting was enabled.

Meanwhile the server-mode process is healthy and registered:

$ ss -tnp | grep "pid=<server>," | grep -c ':443'
1

Ruled out

• remoteControlAtStartup is true in user ~/.claude/settings.json; re-verified immediately before testing
• No false override in any project .claude/settings.json or .claude/settings.local.json
• No /etc/claude-code/managed-settings.json
• ANTHROPIC_BASE_URL=https://api.anthropic.com
• None of DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_GROWTHBOOK is set
• Personal account, so no org policy toggle involved
• The Desktop app spawns the session with --setting-sources=user,project,local, so user settings are in scope

Possible cause

Reading the bundled CLI, the session process does not appear to start Remote Control itself. It resolves the setting and reports it to the host as remote_control_auto_enable, described in the schema as being there "so IDE hosts can mirror TUI behavior." The resolver honours the setting correctly:

function <resolver>(){
  if (get("projectSettings")?.remoteControlAtStartup === false
   || get("localSettings")?.remoteControlAtStartup === false) return false;
  return get("policySettings")?.remoteControlAtStartup
      ?? get("flagSettings")?.remoteControlAtStartup
      ?? get("userSettings")?.remoteControlAtStartup
      ?? config().remoteControlAtStartup
}

So the setting seems to be read correctly and the gap looks like it's on the host side — the Desktop app receiving remote_control_auto_enable: true and not opening the connection. Worth checking whether the Windows/MSIX build mirrors it the way the VS Code extension does.

Workaround

Running one always-on claude remote-control server per project, as a systemd user service, and using those from the phone instead of Desktop-hosted sessions. Works reliably, but it means desk work and phone work are two separate streams that can't see each other.