Bug: enableRemoteControlForAllSessions does not re-arm restored sessions after app restart

Bug: enableRemoteControlForAllSessions does not re-arm restored sessions after app restart

Summary

The setting enableRemoteControlForAllSessions: true in ~/.claude/settings.json correctly auto-enables remote control on newly created conversations, but does NOT re-arm conversations restored via macOS window restoration after a CCD restart. Each restored session only gets armed lazily, on the first LocalSessions.sendMessage call to that session.

For users who restart CCD nightly (RAM hygiene) and rely on mobile / claude.ai remote control across many concurrent conversations, every restored conversation is unreachable from remote control until a message is typed into it.

Repro

1. Set enableRemoteControlForAllSessions: true in ~/.claude/settings.json.
2. Open N conversations and confirm remote control is active on each (verify in claude.ai / mobile).
3. Quit CCD: osascript -e 'tell application "Claude" to quit'.
4. Relaunch: open -a Claude. macOS NSWindowRestoration restores all N conversation tabs.
5. From claude.ai or mobile, attempt to reach any restored conversation. None are reachable.
6. In CCD, type and send any message into one of the restored conversations. That conversation is now reachable from remote control. The other N-1 remain unreachable.

Log Evidence

From ~/Library/Logs/Claude/main.log, sequence captured around a nightly restart:

00:14:13 [sessions-bridge] Reconnecting persisted session cse_012MppULxraVVA3grUXetx9w
00:14:15 [sessions-bridge] Session cse_012MppULxraVVA3grUXetx9w reconnected successfully
00:14:16 [transport:sdk] attaching SDK bridge session cse_012MppULxraVVA3grUXetx9w

Bridge reconnects cleanly. bridge-state.json correctly shows enabled: true, userConsented: true.

Then no Enabling remote control log lines for ~6 hours, until the user wakes the Mac and types into one conversation:

06:52:43 [WarmLifecycle:session] Warming up session local_b97e110c-19aa-4836-b2a8-5f5899662e31
06:52:43 [WarmLifecycle:session] Warming up session local_814f8442-a550-4ade-8d1d-86c8c8922b24
06:52:43 [WarmLifecycle:session] Warming up session local_96f09fa9-d98a-4d40-addd-edc6e417ef06
...
06:52:53 LocalSessions.sendMessage: sessionId=local_b97e110c-19aa-4836-b2a8-5f5899662e31, messageLength=15
06:52:53 Enabling remote control for session local_b97e110c-19aa-4836-b2a8-5f5899662e31
06:52:54 [remote-control] bridge_state: ready
06:52:54 [remote-control] bridge_state: connected

Only local_b97e110c (the conversation that received a sendMessage) got armed. local_814f8442 and local_96f09fa9 were warmed but never armed because no message was sent to them.

Expected Behavior

When enableRemoteControlForAllSessions: true is set, the Enabling remote control for session local_xxx codepath should also fire for every restored session during WarmLifecycle:session, not only on first LocalSessions.sendMessage. Conceptually: the setting promises "all sessions get RC", which today is implemented as "all NEW sessions get RC on creation, all RESTORED sessions get RC on first send" — the second clause is the gap.

Workaround

Send any message in each restored conversation after every restart. With nightly restarts and 5-10 concurrent conversations, this is daily friction.

Environment

• macOS 25.3.0 (Darwin)
• Claude Desktop 1.12603.1
• Single org bridge, bridge-state.json shows persisted enabled: true
• Setting: enableRemoteControlForAllSessions: true

Related Files

• ~/Library/Application Support/Claude/bridge-state.json — project-level bridge state (correctly persisted)
• ~/Library/Application Support/Claude/claude-code-sessions/.../local_*.json — per-conversation state; no remoteControl* field, suggesting RC state is runtime-only
• ~/Library/Logs/Claude/main.log — sequence above