macOS 27: Claude Desktop silently stops updating when Background App Activity is disabled
Summary
On macOS 27, if a user has turned off Claude's background activity (System
Settings → General → Login Items & Extensions), Claude Desktop can no longer
update itself — silently and permanently. The app quits, the update is not
applied, nothing is logged by the updater and nothing is surfaced in the UI.
After three attempts the staged build is discarded and re-downloaded (~868 MB
each round).
Root cause is in Squirrel.Mac, not in Claude, and I filed it upstream with the
full analysis: Squirrel/Squirrel.Mac#336
Short version: ShipIt runs as a launchd job submitted by Claude. It has no
window, no menu bar icon and is not in the Dock, so under macOS 27's Background
App Activity rules it is terminated ~5 s (the job's default ExitTimeOut) after
Claude quits. Claude's pre-move install phase routinely takes longer than that,
so the swap never happens.
Measurements
Same app, same ShipIt binary, same 868 MB bundle, two machines:
| | macOS 26.7 | macOS 27.0 |
|---|---|---|
| installs succeeded | 30 | 12 |
| never completed | 0 | 4 |
| median duration | 5.98 s | — |
| longest successful | 9.64 s | 4.32 s |
| succeeded while >5 s | 25 | 0 |
The median on macOS 26 is 5.98 s. Against a 5 s deadline this is not an
occasional failure — for affected users it is the common case.
Three consecutive failures on the affected machine, each killed mid-install
while hashing the staged bundle for signature validation, before/Applications/Claude.app was touched (so nothing is corrupted — the update
simply never happens).
Why this reaches users who did nothing wrong
The configuration arises naturally. On this machine the owner had seen Claude
show background activity after quitting — that was ShipIt installing an update,
in one case taking 8.4 s — and used the control macOS offers to stop it. macOS
then asked whether to allow it in future, and they declined. From that point the
updater was silently broken.
They were not making a mistake. ShipIt has no way to say what it is doing, so a
user cannot distinguish "installing your update" from "lingering in the
background". As long as that is true, users will keep turning it off.
What Claude Desktop could do (regardless of upstream)
- Notice and say so. Claude has everything needed to detect this: it knows
the version it staged (ShipItState.plist) and the version on disk after the
next launch. If a staged update repeatedly fails to apply, tell the user —
and point at the Background App Activity setting. Today this is completely
silent, and the only visible symptom is the same download happening again
and again.
- Push the upstream fix. Squirrel/Squirrel.Mac#336 lists the options; the
properly conformant one (give the installer a visible presence during the
install, per Apple's documented exemption) needs to land in Squirrel.Mac, and
Electron pulls that repo via DEPS with an empty patch set. Anthropic is a
large Electron consumer and that carries weight.
Workaround for affected users
Turn Claude's background activity back on: System Settings → General → Login
Items & Extensions → Background App Activity.
Environment
macOS 27.0 (26A428), Apple Silicon. Claude Desktop 2.110.1 → 2.2553.1 staged.
Comparison machine: macOS 26.7 (25G229), same app, updates fine.
Evidence, source references and Apple's documentation quotes are in
Squirrel/Squirrel.Mac#336.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗