remoteControlAtStartup not honored when the desktop app resumes a session after auto-update

Additional data point from the same machine: the update-resume path breaks more than Remote Control — it also invalidates TCC Automation grants for the resumed session.

Sequence observed (macOS 26.6, desktop app 1.26832.0):

1. A long-running session's shell is parented by the hosted helper at ~/Library/Application Support/Claude/claude-code/2.1.219/claude.app (com.anthropic.claude-code).
2. The desktop app auto-updates; on disk the helper is now 2.1.222, but the resumed session keeps running the 2.1.219 process.
3. Every AppleScript call from that session now fails with -1743 Not authorized to send Apple events to Finder, even though System Settings → Privacy & Security → Automation shows the claude → Finder toggle ON. Toggling it off/on does not help; tccutil reset AppleEvents com.anthropic.claude-code reports "Failed to reset". TCC appears to bind the grant to the current binary signature while the live process retains the old one.
4. Same restart resolves both symptoms: after a full app relaunch the session runs the current helper, the grant matches again, and (per the original report) Remote Control must also be manually re-enabled.

So the resume-after-update path currently leaves a session half-alive in at least two ways: RC disconnected, and Automation grants dead. Cost here was two aborted 40-minute release pipelines (Finder-scripted DMG styling) before we auto-detected the dead grant and fell back.

Same bug on Windows, and the trigger is broader than auto-update: any restart of the Desktop app reproduces it.

Environment

• Windows 11 Home 10.0.26200, Arm64 (Snapdragon X Plus)
• Claude Desktop app 1.34493.1.0 (MSIX, Arm64); bundled Claude Code engine 2.1.237 (standalone CLI on PATH: 2.1.234)
• ~/.claude/settings.json contains "remoteControlAtStartup": true
• claude.ai account, no API key

So this still reproduces ~15 releases after the 2.1.222 in the original report.

It is not only the auto-update path

I hit this regularly with no update involved at all: I restart the Desktop app to reload an MCP server after adding a tool to it. The app resumes the session, and Remote Control is gone for that session — identical to the post-update symptom.

Evidence from ~/.claude/sessions/*.json on this machine, where a resumed session keeps its sessionId under a new PID:

| sessionId | PID | engine | started (UTC) |
|---|---|---|---|
| ebd5a1b6… | 5456 | 2.1.229 | 2026-08-18 12:20 |
| ebd5a1b6… | 5384 | 2.1.229 | 2026-08-18 15:22 |
| 290da012… | 28692 | 2.1.234 | 2026-08-20 17:22 |
| 290da012… | 20400 | 2.1.235 | 2026-08-21 20:29 |

The first pair is the telling one: same engine version on both sides, so that resume was a plain app restart, not a version swap. The Remote Control loss is on the resume path itself.

What it looks like from the phone

The session's row in the Claude mobile app's Code tab goes to disconnected and stays there. Continuing to work in that session on the desktop — new messages, tool calls, another hour of turns — never brings it back. Only a manual /remote-control, or starting a fresh session, restores it.

Worth noting for triage: new Desktop Code sessions on this build do register and show up on the phone, so #84502's "never registered" is not the whole story on current builds — registration works at session start and simply is not re-run on resume.

Mechanically

A resumed Code session on this build is spawned headless, with no remote-control argument (session ID, allowed tools and plugin dirs trimmed):

%APPDATA%\Claude\claude-code\2.1.237\claude.exe --output-format stream-json --verbose
  --input-format stream-json --model claude-opus-5 --permission-prompt-tool stdio
  --resume=<session-uuid> --setting-sources=user,project,local --permission-mode auto
  --include-partial-messages --replay-user-messages --settings {}

The host still holds the identity it needs — it hands the original sessionId straight back in --resume — so re-attaching the existing Remote Control registration is a lookup on a key it already has.

Two things that would fix it

1. Re-register on resume, honoring remoteControlAtStartup / the Desktop toggle on the resume path, not only on first start.
2. As a backstop, re-register lazily on the next user message. This recovery already exists for a different host type — 2.1.238 shipped "Fixed a Remote Control session whose process crashed staying unavailable until claude remote-control was restarted; it can now be reused when you next message it." That is exactly the behavior needed here; it just was not applied to Desktop-hosted resumed sessions.

Related: 2.1.236 added "Remote Control now marks a session offline within seconds when the CLI exits or its terminal closes", which is presumably why the stale row flips to disconnected so promptly now — but nothing marks it back online when the same session returns under a new PID seconds later.

This also matches #82462 (registration lost after /clear) and #80400 (lost after resume-from-sleep): every path that re-enters an existing session skips the Remote Control connect step, with no recovery short of a manual /remote-control.

Corroborating on 2.1.246 (native desktop bundle, macOS arm64, Darwin 25.6.0): this is not only the auto-update path — a manual quit + relaunch + resume reproduces it every time. From then on the resumed session's PushNotification returns "Mobile push not sent (Remote Control inactive)"; the session also drops off claude.ai/code's active session list (dimmed offline row) and the iOS app reports "no active code session". remoteControlAtStartup: true and the desktop "Enable remote control by default" preference were both verified not honored across a second restart performed after setting them, and the iOS app attaching doesn't re-arm the bridge either (we haven't tried the manual /remote-control path mentioned above). Current workaround: abandon resume entirely — start a fresh session after every app restart.