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:

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)

1. 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.
2. 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.

Start with Squirrel/Squirrel.Mac#336 and the ShipItState.plist/version comparison described in the report, then trace how Claude Desktop stages and applies updates. Determine whether this repository owns the detection and UI work or whether the fix belongs upstream in Electron/Squirrel.Mac; completion requires an agreed scope and a verifiable handling of failed updates.