[BUG] Desktop app stealth auto-update relaunches while sessions are hosted for Remote Control, dropping every remote connection
Preflight Checklist
- [x] I have searched existing issues and this is not a duplicate
- [x] I am using the latest version of Claude Code / the desktop app
- [x] This is a bug report, not a feature request
What's Wrong?
I host Claude Code sessions in the Claude desktop app on a Mac and drive them from my phone through Remote Control, so the Mac gets no local keyboard or mouse input for hours at a time.
The desktop app treated that as "idle" and relaunched itself to install an update while four sessions were live and remote-controlled. Every Remote Control connection dropped at once, and nothing re-served the sessions until I was physically back at the Mac. No crash, no sleep, no network or auth problem: the app's own log shows a stealth update triggered by an idle timeout, ten minutes after the update finished downloading.
The sessions themselves survived (the relaunch restored all 23 navigation entries and the sessions were resumable locally). What was lost was their remote reachability, which for a remote-controlled machine is the whole point.
What Should Happen?
- The stealth updater should not relaunch the app while any session is hosted for Remote Control, or at minimum while a remote client is connected. System idle is the normal state of a machine being driven remotely, so it is the wrong signal here.
- After any relaunch, sessions that were hosted for Remote Control before it should be re-served automatically, so the phone can reconnect without someone touching the Mac.
- A user-facing way to defer or disable auto-updates would let people who manage their own updates avoid this entirely. The only control today is the
disableAutoUpdatesenterprise policy key documented for MDM.
Error Messages/Logs
From ~/Library/Logs/Claude/main.log, 2026-09-17 (local time):
15:02:06 [info] [updater] Found an update, downloading
15:02:11 [info] [updater] Update downloaded and ready to install { releaseName: 'Claude 2.2553.0' }
15:12:07 [info] [WarmLifecycle:session] Idle timeout disabled, not arming for local_579c...
15:12:09 [info] [WarmLifecycle:session] Idle timeout disabled, not arming for local_bf6e...
15:12:11 [info] [updater] Staged version 2.2553.0 is still current (latest: 2.2553.0, lastTarget: null)
15:12:15 [info] [WarmLifecycle:session] Idle timeout disabled, not arming for local_bd39...
15:12:41 [info] [stealth-update] Triggering stealth update after idle timeout
15:12:41 [info] [stealth-relaunch] Saved navigation history (23 entries, active=22)
15:12:42 [info] beforeQuitForUpdate handler fired, going down for update
15:12:52 [info] Starting app {
15:12:52 [info] [updater] Version changed since last launch: 2.110.1 -> 2.2553.0
15:12:52 [info] [stealth-relaunch] Restoring navigation (23 entries, active=22, dropped=0)
Note the three "Idle timeout disabled, not arming" lines in the same minute: the session lifecycle knew the sessions were active, and the updater relaunched anyway.
Steps to Reproduce
- On macOS, open the Claude desktop app, Code tab, and start one or more sessions connected to Remote Control.
- Drive them from the Claude mobile app (or claude.ai/code) without touching the Mac's keyboard or mouse.
- Wait for a desktop app update to be downloaded and staged.
- Keep working from the phone; once the Mac's system idle time passes the stealth-update threshold, the app relaunches itself.
- Observe that every Remote Control connection drops and the sessions are not reachable from the phone again until someone interacts with the app on the Mac.
Is this a regression?
Not sure. This is the first time I have caught it in the log; a previous unexplained loss of all remote sessions looked the same from the phone.
Claude Code Version
Desktop app 2.110.1 -> 2.2553.0 (macOS, Apple silicon), bundled Claude Code 2.1.271 -> 2.1.274. Standalone CLI on the same machine: 2.1.274 (Claude Code), not involved.
Platform
Claude desktop app (Code tab) with Remote Control; Claude subscription (not API).
Operating System
macOS 27.2, Apple silicon.
Terminal / Install method
Claude desktop app installed from the Homebrew cask claude; the app self-updates.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Happened again on 2026-09-28, the third time now, with the same result: every Remote Control connection dropped while I was away from the Mac, and nothing reconnected until I was back at the machine.
Environment
Timeline (CDT, UTC-5), from
~/Library/Logs/Claude/main.log[stealth-update] Triggering stealth update after idle timeout[CCD] CLI exit before update: 11 of 11 exited within 1547msremote-tools-device) reconnects on its own[remote-control] bridge_state: "connected", only after I reopened the sessions at the MacSo the sessions survive the relaunch, and the device bridge comes back within seconds, but Remote Control for the Code sessions does not: for about six and a half hours none of the 11 sessions could be reached from my phone.
The idle trigger is what makes this bite: a Mac that hosts sessions for Remote Control is idle precisely because its user is away. Either Remote Control should reconnect by itself after a stealth relaunch, or the stealth update should wait while sessions are connected to Remote Control.
As a workaround I have now set
defaults write com.anthropic.claudefordesktop disableAutoUpdates -bool true, and will report here whether the app honors it when set per user rather than through a managed profile.Hitting the same issue on macOS. I run the desktop app on a MacBook (lid closed, on power, system sleep disabled), turn on Remote Control for a session, and use it from the Claude app on my phone. The Mac is "idle" but I'm actively working remotely, and the session gets killed by the stealth update.
From
~/Library/Logs/Claude/main.log:After the relaunch, reconnecting to the earlier session fails:
No sleep events in
pmset -g logand the network was up at those times, so the relaunch itself is what drops the session.Would like to see:
Environment: macOS (Darwin 25.6.0), Claude desktop 2.16120.0 (previously 2.9939.4), Claude Code 2.1.284.
Follow-up on the per-user setting from my last comment: it is not honored.
Since 2026-09-28 21:30 (CDT, UTC-5)
disableAutoUpdateshas been set to 1 in my own preferences (defaults write com.anthropic.claudefordesktop disableAutoUpdates -bool true, confirmed withdefaults read). The app kept updating, and relaunched silently again. From~/Library/Logs/Claude/main.log:[updater] Update downloaded and ready to install { releaseName: 'Claude 2.19675.0' }[stealth-update] Triggering stealth update after idle timeout[updater] App is installed, enabling initial check and auto-updatesSo the key is not read from the user domain. I have not tried it as a managed preference through a configuration profile. A way to keep the idle relaunch from firing while sessions are hosted for Remote Control would still be the real fix.