remoteControlAtStartup ignored for Claude Desktop Code-panel sessions (bundled v2.1.119)

Summary

When remoteControlAtStartup: true is set in ~/.claude/settings.json, sessions launched from the Claude Desktop Code panel (</>) do not auto-bridge to Remote Control. They never appear in the iPhone Code tab. Existing entries on the iPhone show as "Disconnected." Terminal-launched claude sessions work correctly.

Root cause (verified)

Claude Desktop bundles its own copy of Claude Code at:

~/Library/Application Support/Claude/claude-code/<version>/claude.app/Contents/MacOS/claude

‚Ķand the Code panel always invokes the bundled binary, ignoring whatever is on the user's PATH. On my machine the bundle is v2.1.119 ‚Äî which has the Remote Control "stuck on Idle" / no-re-login-on-transient-auth bugs that v2.1.121 fixes. Running claude update only updates the user's PATH binary; the bundled binary is untouched and Desktop has no UI to update it independently of the Desktop app version itself.

Environment

• macOS (Apple Silicon)
• Claude Desktop 1.4758.0
• Bundled claude-code: 2.1.119 (~/Library/Application Support/Claude/claude-code/2.1.119/claude.app/Contents/MacOS/claude)
• PATH claude-code (after claude update): 2.1.121 (~/.local/bin/claude)
• Setting: remoteControlAtStartup: true in ~/.claude/settings.json (user scope)

Reproduction

1. Confirm remoteControlAtStartup: true in ~/.claude/settings.json.
2. From a terminal, run claude and complete /login. Observe: the session appears on the iPhone Code tab as Connected. ‚úÖ
3. Launch Claude Desktop. From the </> Code panel, start a new session in any cwd.
4. Wait several minutes. Observe: the session never appears on the iPhone Code tab. ‚ùå
5. Inspect the launched process — it is the bundled v2.1.119 binary, not the PATH binary.

Evidence

Process tree of a Code-panel session (abridged):

/Users/<user>/Library/Application Support/Claude/claude-code/2.1.119/claude.app/Contents/MacOS/claude \
  --output-format stream-json --verbose --input-format stream-json \
  --model claude-opus-4-7 --setting-sources=user,project,local \
  --permission-mode auto --allow-dangerously-skip-permissions \
  --include-partial-messages --plugin-dir … --managed-settings {} \
  --replay-user-messages --settings {}

Session metadata file (~/.claude/sessions/<pid>.json) confirms entrypoint:"claude-desktop", kind:"interactive", version:"2.1.119".

The launch command does not pass any --remote-control flag, but --setting-sources=user,… is included, so user-scope remoteControlAtStartup: true should be honored. Whether it's honored and silently failing to bridge, or never read, isn't visible from outside.

Expected vs actual

• Expected: With remoteControlAtStartup: true, every new Code-panel session bridges to Remote Control on launch and appears on the iPhone Code tab as Connected within ~15s.
• Actual: Code-panel sessions never bridge. Terminal sessions on the same setting bridge fine.

Proposed fixes (not mutually exclusive)

1. Ship a Desktop update that bumps the bundled claude-code to ≥ 2.1.121. This is the simplest path — it inherits the existing RC fixes.
2. Make the bundled binary's auto-update independent of the Desktop app version. Desktop's ~/Library/Application Support/Claude/claude-code/<version>/ directory implies versioning, but there's no user-visible mechanism to advance it. A "check for Claude Code update" inside Desktop, or a periodic background fetch, would close the gap.
3. Allow Desktop to honor a user override pointing at a PATH binary, e.g. claudeCodeBinaryOverride in settings, for advanced users who want to roll forward independently.
4. Surface a clearer "Disconnected" state on the iPhone Code tab with the underlying reason (auth, network, version-incompatible peer protocol) so users can triage without reading process trees.

Workarounds tried

• claude update to 2.1.121 ‚Üí only updates PATH binary, Code panel still uses bundle. No effect.
• Quit and relaunch Claude Desktop ‚Üí fresh sessions still spawn the same bundled v2.1.119. No effect.
• /login in a terminal claude ‚Üí confirms auth is fresh; terminal sessions bridge fine, Code panel still doesn't. Rules out auth.
• Manual /remote-control in a Code-panel session ‚Äî not yet retested on 2.1.119; if it works, it confirms the bridge is reachable but remoteControlAtStartup is not being applied at startup specifically.

Risk to users

For anyone relying on the iPhone Code tab to drive desktop sessions, the auto-bridge is the default expectation set by remoteControlAtStartup. Silently failing for the most common launch path (Code panel) makes the setting feel broken.