[BUG] Windows non-MSIX (Squirrel): update feed returns 403 to Update.exe - auto-update fails silently and pins the app on an old version

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On the non-MSIX (Squirrel) Windows build, auto-update has been failing silently since 2026-08-09. Update.exe gets HTTP 403 from the update feed on every check. The Electron layer logs only Auto-update error: Error: Command failed: 4294967295 (0xFFFFFFFF, Update.exe's exit code) and carries on. Nothing surfaces in the UI.

The app has now been pinned at 1.26832.0 for four days while the feed serves 1.28929.0.

Environment: Claude Desktop 1.26832.0 installed via Claude Setup.exe --exe (Squirrel, not MSIX), Windows 11 10.0.26200. Relevant because the non-MSIX build is currently the recommended workaround in #81341 / #83028 for the CIG / vk_swiftshader.dll GPU crash — users moving there to escape that bug land on a build whose updater is broken, and they have no way to notice.

The same request from the same machine succeeds. Using System.Net.WebClient — the same .NET class Squirrel's FileDownloader uses — against the exact URL taken from Squirrel's own log:

200 OK
5AEDC76B51EE0D91AA8FCBE8C52E06EB99CB1DC6 https://downloads.claude.ai/releases/win32/x64/AnthropicClaude-1.28929.0-full.nupkg 236511608

So the 403 is specific to the request Update.exe actually issues — not to the URL, the host, or the network path.

Ruled out:

| Hypothesis | Test | Result |
|---|---|---|
| Enterprise policy disabling updates | HKLM\SOFTWARE\Policies\Claude, HKCU\SOFTWARE\Policies\Claude, HKLM\SOFTWARE\Policies\Anthropic | all three absent |
| Feed is empty / no newer build exists | GET the feed | 200, serves 1.28929.0 |
| Host-specific edge rule | api.anthropic.com vs releases.claude.com | both 200, identical body |
| User-Agent filtering | raw WebClient (sends no UA header) vs PowerShell's default UA | both 200 |
| Legacy TLS from .NET Framework | forced TLS 1.0 and 1.1 | handshake failure, not 403 |
| Path case sensitivity | /RELEASES vs /releases | lowercase gives 404, not 403 |

What Should Happen?

1. The update feed should not return 403 to the app's own updater when an identical request from another client on the same machine returns 200.

1. A failing update check must be visible to the user. Today the only evidence is one line in main.log and a stack trace in Squirrel-CheckForUpdate.log. There is no UI indication and no update state shown anywhere, so several days of silent staleness is indistinguishable from being up to date. This is the more serious half of the report: whatever causes the 403, a permanently-failing updater should not be silent.

1. Command failed: 4294967295 should be surfaced with the underlying HTTP status rather than a raw exit code, so the failure is diagnosable without digging into Squirrel's own log.

Error Messages/Logs

%APPDATA%\Claude\logs\main.log:

2026-08-12 10:25:01 [info]  [updater] Update URL: https://api.anthropic.com
2026-08-12 10:25:01 [info]  [updater] Checking for updates
2026-08-12 10:25:03 [error] [updater] Auto-update error: Error: Command failed: 4294967295

%LOCALAPPDATA%\AnthropicClaude\Squirrel-CheckForUpdate.log:

[12/08/26 10:25:03] fatal: Finished with unhandled exception: System.AggregateException: One or more errors occurred.
 ---> System.Net.WebException: The remote server returned an error: (403) Forbidden.
   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.Net.WebClient.GetWebResponse(WebRequest request, IAsyncResult result)
   at System.Net.WebClient.DownloadBitsResponseCallback(IAsyncResult result)
   at Squirrel.Utility.<LogIfThrows>d__43`1.MoveNext()
   at Squirrel.FileDownloader.<DownloadUrl>d__3.MoveNext()
   at Squirrel.UpdateManager.CheckForUpdateImpl.<CheckForUpdate>d__2.MoveNext()
   at Squirrel.UpdateManager.<CheckForUpdate>d__8.MoveNext()
   at Squirrel.Update.Program.<CheckForUpdate>d__8.MoveNext()

Requested URL, from Squirrel's own log (device_id redacted):

https://api.anthropic.com/api/desktop/win32/x64/squirrel/update/RELEASES
    ?device_id=<redacted>&id=AnthropicClaude&localVersion=1.26832.0&arch=amd64

Failure timeline — fatal: entries in Squirrel-CheckForUpdate.log (timestamps are dd/MM/yy). 98 lines mention 403 across a 2090-line log:

08/08   11:18, 15:18, 20:13     checks ran, no fatal
09/08   11:47, 11:51, 19:13, 20:13, 21:13, 22:13
10/08   11:30, 15:46
11/08   09:22
12/08   10:25

Install date was 08/08. The first day's checks completed; every check since 09/08 has failed.

Steps to Reproduce

1. Install Claude Desktop on Windows with Claude Setup.exe --exe, which forces the Squirrel (non-MSIX) build.
2. Leave the app running past an update check. Checks run at startup and roughly hourly.
3. Inspect Squirrel's log:

Get-Content "$env:LOCALAPPDATA\AnthropicClaude\Squirrel-CheckForUpdate.log" -Tail 40

Look for (403) Forbidden.

1. Take the URL from that log and fetch it directly with the same .NET class Squirrel uses:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
(New-Object System.Net.WebClient).DownloadString(
  'https://api.anthropic.com/api/desktop/win32/x64/squirrel/update/RELEASES?device_id=<yours>&id=AnthropicClaude&localVersion=<yours>&arch=amd64')

1. Observe: the app's updater gets 403; the direct fetch returns 200 and names a newer build than the one installed.

Is this a regression?

Yes — update checks completed on install day (08/08) and have failed on every check since 09/08, with no app-side change in between.

Last Working Version

1.26832.0 (the currently installed build; the updater worked on 08/08 and stopped on 09/08)

Claude Code Version

2.1.222 — the bug is in Claude Desktop 1.26832.0 (non-MSIX / Squirrel), filed here as there is no separate Desktop repo

Operating System

Windows 11 10.0.26200

Additional Information

Note for triage: app.asar carries a setting UpdateViaUpdatesHost (default off) whose description says it exists so that networks blocking api.anthropic.com at the edge can read the feed from releases.claude.com instead. That is a different failure mode from this one — here api.anthropic.com is fully reachable from the affected machine and returns 200 to every client tested except the app's own updater.

The device_id from the failing requests can be provided privately if it helps correlate against edge logs.

Workaround: re-running Claude Setup.exe --exe pulls the current build straight from downloads.claude.ai and bypasses the update check entirely. That is a manual step a user only takes if they already suspect they are stale — which, given point 2 above, they have no reason to.