[BUG] Desktop (Windows/Squirrel): a staged update is applied on any relaunch, not just "Relaunch to update" - silently moving users off a deliberately pinned build

Why this is not a duplicate of #86012

#86012 is a cross-session messaging regression in the CLI engine. This is a defect in the Squirrel updater and execution stub in the Desktop app. Different subsystem, different failure mode, and it would still be a problem if #86012 were fixed tomorrow. #86012 is the reason it currently hurts, not the reason it happens.

Summary

Claude Desktop presents "Relaunch to update" as a consent gate. It is not one. Once Squirrel has staged and extracted a new build, the execution stub at the install root resolves to the newest app-* directory, so any restart applies the update — a reboot, an OS update, a crash, or simply quitting and reopening the app. The user is never asked again and never told it happened.

For anyone deliberately holding a known-good version — which right now includes everyone working around #86012 — this converts a deliberate pin into a silent roll-forward.

Environment

| | |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| Install type | Squirrel (unpackaged), %LOCALAPPDATA%\AnthropicClaude |
| Running build | 1.25927.0 (deliberately pinned) |
| Staged build | 1.30096.1, downloaded and fully extracted without prompting |

Evidence

From %LOCALAPPDATA%\AnthropicClaude\Squirrel-Update.log, unattended, no user action (paths redacted):

[13/08/26 18:54:41] FileDownloader: Downloading file:
    https://downloads.claude.ai/releases/win32/x64/AnthropicClaude-1.30096.1-full.nupkg
[13/08/26 18:54:45] ApplyReleasesImpl: Writing files to app directory:
    C:\Users\<user>\AppData\Local\AnthropicClaude\app-1.30096.1
[13/08/26 18:54:46] LogHost: Rigging execution stub for claude_ExecutionStub.exe to
    C:\Users\<user>\AppData\Local\AnthropicClaude\claude.exe

The new build is fully on disk (2400 files, 561 MB) while 1.25927.0 is what is running. The only thing standing between the user and the new build is a process restart.

Second, related defect in the same log

[13/08/26 18:54:56] cleanDeadVersions: exclude current version folder app-1.28929.0
[13/08/26 18:54:56] cleanDeadVersions: exclude new version folder app-1.30096.1

cleanDeadVersions protects the version Squirrel believes is current and the incoming one. The build that is actually executing (app-1.25927.0) is on neither list, and was eligible for deletion while running. It survived, as far as I can tell only because its files were locked. A user's running install should not depend on a file lock to avoid being garbage-collected.

Third: DISABLE_AUTOUPDATER is actively misleading here

Claude Desktop injects DISABLE_AUTOUPDATER=1 into the environment of every CLI child process it spawns — visible in the app bundle as the child-env constructor:

return { DISABLE_AUTOUPDATER: `1`, ... }

So a user who inspects a running session's environment sees DISABLE_AUTOUPDATER=1 and reasonably concludes auto-updating is off. It is not: that variable governs the CLI's self-update, and the Desktop Squirrel updater consults no environment variable at all. I checked — the only gate on the Desktop update path is autoUpdate.disabled, sourced from machine-scoped policy (the HKLM policy hive on Windows), which is admin-only and explicitly documented as not honored from user-writable stores.

The result is that the one signal a user is likely to find says "updates are disabled" while the updater that matters is unaffected by it.

Expected behaviour

1. A staged update should not be applied by an incidental restart. Either apply only via the explicit "Relaunch to update" action, or state plainly in the prompt that the next launch of any kind will apply it.
2. Provide a supported, user-reachable way to decline or defer a specific version. Today the only mechanisms I have found are enterprise policy (autoUpdate.disabled via the HKLM policy hive, admin-only and not intended for individuals) or filesystem tricks against Squirrel.
3. cleanDeadVersions should exclude the version that is actually running.

Impact

Users pinned to a working build to avoid an open, confirmed regression (#86012) are moved onto a build that still carries it — 1.30096.1 ships engine 2.1.229, which contains no fix for that issue — without an explicit action or notice.