Claude Desktop (macOS): auto-update relaunches the app and silently kills live session hosts — no way to disable it

Status Fixed / completed
Reported on v2.1.221
Maintainer reply None cached
Activity 2 comments · opened Aug 10, 2026 · closed Aug 25, 2026

Environment

  • Claude desktop 1.25927.0 (updated from 1.24012.9), Claude Code 2.1.221
  • macOS 26.3 (25D125), Mac Studio M3 Ultra
  • Headless ML box driven remotely from a phone; sessions and jobs are expected to run for days

What happened

On 2026-08-06 11:20:22 the desktop app auto-updated 1.24012.9 → 1.25927.0 and relaunched itself. The relaunch terminated the CLI processes hosting my live Claude Code sessions, and with them the remote-control link I use from my phone. I was travelling, so I could not restore it from the machine. I got back three days later. Three days of research time lost on a box whose entire purpose is running long jobs.

The failure is invisible by design. From ~/Library/Logs/Claude/main.log at relaunch:

2026-08-06 11:20:23 [info] [update-restart] Detected nav-restore marker, launching normally
2026-08-06 11:20:23 [info] [stealth-relaunch] Restoring navigation (50 entries, active=49)

The window returns looking exactly as it was left, so nothing indicates that the processes underneath were killed. There was no warning before, and no notice after.

I ruled out my own infrastructure before filing:

  • The machine never rebooted or slept — uptime was 10 days at diagnosis, no shutdown or sleep events
  • The network was fine — the app's own [remote-tools-device] channel logged 160 reconnects in the window, every one #1 (first-try success), with no gap over 45 minutes
  • The app relaunch at 11:20:22 was the only discontinuity in three days

It was also armed to happen again. A further build (1.26832.0) was staged at 2026-08-06 19:20 and its ShipIt installer sat blocked for 2 days 22 hours waiting for the app to quit — 795 MB parked in ~/Library/Caches/com.anthropic.claudefordesktop.ShipIt/, with ShipItState.plist pointing at /Applications/Claude.app, ready to fire on the next restart. This is not a one-off; it is a standing trap for anyone who leaves a session running.

There is no way to turn this off

I looked for a supported control and found none:

  • Nothing in the app UI
  • No key in com.anthropic.claudefordesktop preferences
  • Nothing in ~/Library/Application Support/Claude/config.json

Note for triage: #84732 states that autoUpdates / DISABLE_AUTOUPDATER already provide an opt-out. Those are Claude Code CLI settings. They do not govern the desktop app's Squirrel/ShipIt updater, which is the mechanism that relaunches the app and kills the session hosts. As far as I can tell that updater has no user-facing off switch at all.

Requests

  1. A documented setting to disable or defer desktop app auto-updates. On a machine with uptime expectations, updating must be a deliberate act taken when nothing is in flight.
  2. Never relaunch while sessions are live. Stage the update and apply it on the next user-initiated quit.
  3. Say so when it happens. If an update does terminate session hosts, surface that on relaunch instead of restoring navigation state so the break looks like nothing occurred. [stealth-relaunch] is reasonable for a chat window and wrong for something supervising long-lived processes.
  4. Reattach or offer to resume the sessions that were killed.

Request 3 is what turned a lost session into a lost trip. Had the app told me my sessions were gone, I would have reconnected from my phone in a minute.

Workaround I had to build

ShipIt is submitted as a launchd job rather than an on-disk plist — killing the process gets it respawned in under a second — so the only durable handle is the label:

launchctl disable gui/$UID/com.anthropic.claudefordesktop.ShipIt
launchctl bootout  gui/$UID/com.anthropic.claudefordesktop.ShipIt
chflags uchg ~/Library/Caches/com.anthropic.claudefordesktop.ShipIt   # nothing can be staged

That holds, and it survives reboots. Reverse-engineering an SMJobSubmit label should not be the supported path to "don't restart my machine's tooling while I'm away".

Related

Same failure class, different platform or component: #84732 (Windows, forced update kills a 6-day job, file lock), #78046 (Linux, CLI daemon transition reaps background tasks), #84071 (native auto-update invalidates TCC grants, breaks headless automation), #78538 (ShipIt fails to relaunch after installing).

Submitted via in-app feedback as reference 43ea19c5-589d-47f1-a333-d0beaf79da87.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗