[BUG] Claude Desktop on Windows loops on "A new version of Claude is available" with error 1XAF0WC after update

I have the same issue, i just deleted the cache folder inside of appdata (%APPDATA%\Claude\Cache) and now its working again.

Same issue but resolved by deleting cache at this location:
C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude

Thanks for the very thorough writeup, it saved me a lot of guesswork this morning. I ran into the same thing on a newer build and wanted to add what I found, including one result that points away from the current explanation.

My setup

Claude Desktop 1.30096.5.0, installed from the Microsoft Store (MSIX, package family Claude_pzs8sxrjxfjjc), Windows 11 Pro 10.0.26200. Node 24.18.0 according to the Starting app log line.

What happened

The Store updated the package at 09:40:46. My Electron cache folders had not been written since June 11 and June 16, so they were about two months old. The first failure came 4.5 minutes later, on the first launch:

09:45:15 [warn]  [spa] chunk preload failed; running diagnostics, then reloading
                 TypeError: Failed to fetch dynamically imported module:
                 https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/cf52a4cc1-hbzHgoxq.js
09:45:16 [error] [BOOTSTRAP] Fatal error boundary triggered {"errorCode":"1XAF0WC","url":"/epitaxy"}
09:45:46 [warn]  [BOOTSTRAP] Background chunk load failed; nobody is waiting on it, not reloading
                 {"decision":"allow","url":"/epitaxy","chunk_id":"c71860c77","chunk_ext":"js",
                  "chunk_load_origin":"registry","preload_entry_id":"settings_panel_claude_code",
                  "preload_tier":"T1"}

I got 11 of these 1XAF0WC events across five launch attempts, at 09:45, 09:46, 09:47, 10:00 and 10:03.

The assets are actually fine

This is the part I did not expect. I fetched every chunk URL mentioned in this issue and in #64960, from the same machine that was failing:

• cf52a4cc1-hbzHgoxq.js, HTTP 200, 76285 bytes (mine, the one that kept failing)
• cd377abb5-BIgStjBb.js, HTTP 200, 22012 bytes (mine, the one at the fatal boundary)
• cd377abb5-CyivASTZ.js, HTTP 200, 46352 bytes (yours)
• cf52a4cc1-DaHTBzOx.js, HTTP 200, 2734 bytes (yours)
• cf52a4cc1-Da2FnJQI.js, HTTP 200, 2938 bytes (from #64960)

All 200, all text/javascript, which lines up with the check you already did. #64960 explains the bug as chunk hashes that no longer exist on the CDN and therefore 404, but that does not look like what is happening, at least not here. The files are served fine to the OS, and the same fetch fails inside Electron. That puts the problem in the local cache rather than on the CDN or in the network.

It also explains why the error screen sends you the wrong way. It says to check your connection, so you go and audit DNS, proxies and firewalls, and there is nothing wrong with any of it. I checked anyway, for the record: no outage that day, DNS resolved normally for claude.ai, assets-proxy.anthropic.com and api.anthropic.com, netsh winhttp show proxy reported direct access, ProxyEnable was 0, the hosts file was empty, 50 GB of RAM free, and no third party antivirus (only Defender). It is also not the QUIC problem from #65885, since there is no ERR_QUIC_PROTOCOL_ERROR or -356 anywhere in main.log.

The same two chunks keep turning up

Across the three reports, on two operating systems and over roughly two and a half months, it is the same two chunk ids with different content hashes, always on /epitaxy. cf52a4cc1 shows up in #64960 (June, macOS), here (July) and in mine (August). cd377abb5 shows up here (July) and in mine (August).

That feels like something specific about those preload entries rather than the whole cache going stale. My logs tag them with chunk_load_origin: "registry", preload_entry_id: "settings_panel_claude_code" and preload_tier: "T1", in case that helps narrow things down.

One difference worth flagging for Windows users

In #64960 on macOS, a second launch always works, and the advice there is simply to quit and reopen. That does not work on Windows. I tried five times, checking that no Claude.exe processes were left behind each time, and every attempt failed the same way, just as you found. Clearing the cache was the only thing that helped.

About the cache path

@akinu is right, and it may be worth folding into the issue body, because the paths in the original report cannot work for anyone who installed from the Store. %APPDATA%\Claude does not exist at all on an MSIX install. Filesystem virtualization moves it, and the app even says so in the log: [MSIX] Filesystem virtualization active. The real location is:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\

The logs live in ...\Claude\logs\main.log and ...\Claude\logs\claude.ai-web.log. Anyone on the Store build who follows the original steps will find nothing there to delete, and will quite reasonably conclude the workaround is not meant for them.

Deleting Cache, Code Cache and GPUCache in that folder, after closing every Claude.exe under C:\Program Files\WindowsApps\Claude_*, fixed it straight away. The folders were recreated, the app logged boot: done, and I have not seen 1XAF0WC since.

On the related issues

#64960 is the closest match and I think it deserves another look. Same error code, same /epitaxy import, same cf52a4cc1 chunk id. It adds something a single report cannot show on its own, which is that this happens on every version bump rather than occasionally. It was closed by the stale bot in July rather than by a fix.

The comments on it are worth rereading as well. Someone made the point that [spa] chunk preload failed means a recovery path is already running, and that a soft location.reload() just requests the same document again. Since that document is the stale thing sitting in the cache, the reload resolves the same broken chunk references and falls back into the fatal boundary. The suggestions there were to make that recovery reload cache busting with webContents.reloadIgnoringCache() behind a one shot flag, to have the error boundary treat a failed dynamic import as recoverable and hard reload once instead of showing the fatal screen, and to serve the navigation document with Cache-Control: no-cache while long caching only the hashed assets.

My logs seem to support that reading. [spa] chunk preload failed; running diagnostics, then reloading fires on four separate launches and still ends at the fatal boundary each time, so whatever reload it performs is not clearing the bad cache entry. There is also a second path, Background chunk load failed; nobody is waiting on it, not reloading, which flips from "decision":"allow" to "decision":"hidden" between launches.

#76430 carries the same error code during an update, but the report itself is really about missing sidebar sessions, so I suspect that is a different symptom rather than the same bug.

#65885 has a different cause (QUIC), but it is the other MSIX blank screen report on Windows, and the two are easy to mix up, so linking it might save a bit of triage time.

Given that #64960 is macOS and this one is Windows, with the same error code, route and chunk ids, this looks like a cache invalidation problem on update rather than anything specific to MSIX. MSIX just changes where the cache lives, makes the documented workaround unusable, and seems to remove the cold restart that macOS users can fall back on.

Happy to pull any other logs or run further tests if that would be useful.

@DrRIH's writeup matches mine almost point for point, so I'll skip what's already covered and
add three things I don't think are in the thread yet: a deliberate reproduction, a case
with no app update involved at all, and the mechanism behind the Windows "restart doesn't
help" behaviour.

Environment: Windows 10 22H2 (10.0.19045), Claude Desktop 1.44121.4 (MSIX /
windows-store), Electron 42.10.0, Chrome 148.0.7778.280. Newer than both builds reported so
far, so this is still present.

1. It happens without any app update

This is the part that I think reframes the issue title. #64960 describes it as happening on
every update, @DrRIH's began 4.5 minutes after a Store package update, and this report is
"after update". Mine had no update whatsoever — the updater ran hourly all day and staged
nothing; I checked the whole window in main.log.

What actually changed while the app sat idle was a claude.ai web deploy (web commit
1d3fa81b… → 231c0b29…). The app then failed on first focus 9.5 hours later.

So the trigger looks like a renderer cache that predates the currently-served web build. An
app update is one reliable way to reach that state, but it isn't required — which suggests
"invalidate on app update" wouldn't be a complete fix.

2. Reproduction

Precondition is just a profile cache captured before a claude.ai web deploy and restored
after it. One deploy boundary is enough - my original incident straddled a single deploy.

1. Use the app normally, visiting Claude Code at least once. Quit, copy Cache/,

Code Cache/, GPUCache/ aside (container path as @DrRIH describes).

1. Wait for, or ship, one web deploy.
2. Quit, restore the three directories, relaunch.
3. Chat works fine.
4. Click Claude Code → the window is replaced by the error screen.
5. Relaunching does not help.
6. Deleting the three directories fixes it.

I reproduced this on demand after the fact, so it should be reproducible internally in
minutes by staging a pre-deploy cache against a current build.

3. Why restart doesn't help on Windows

@DrRIH found five relaunches all failing, and macOS recovering on a second launch. I think
this explains the difference: the last-used surface is persisted in localStorage — the
string epitaxy appears 260× in Local Storage/leveldb. Every relaunch restores /epitaxy,
which is precisely the route that dies, before any UI is reachable.

Local Storage/ is not one of the three directories the workaround deletes, so the trap
survives the restart entirely. The only escape I found is the tray quick-entry dialog, which
forces a /new navigation instead of letting the SPA restore its saved surface.

That suggests a cheap partial fix independent of the cache question: on fatal boundary,
clear the persisted route and fall back to /new.

4. The failure is route-scoped, but the error boundary is global

Worth separating from everything above, because it's verifiable from your own telemetry
without agreeing with any cache theory. The same chunk fails on /new and the app shrugs:

2026-09-04 00:11:31 [warn] [BOOTSTRAP] Background chunk load failed; nobody is waiting on it, not reloading
{"decision":"allow","url":"/new","chunk_id":"cf52a4cc1","chunk_ext":"js","chunk_load_origin":"registry","preload_entry_id":"code_product_chunk","preload_tier":"T1","preload_source":"idle","preload_render_joined":false,"preload_prime":"ok"}

Chat, sidebar and history all keep working. On /epitaxy the identical rejection reaches the
global [BOOTSTRAP] boundary and blanks the entire window.

Why the chunk fails is the unresolved part. But *a speculative, non-render-critical preload
rejection being able to reach the global fatal error boundary* is an application-level defect
that stands on its own, and fixing it alone would downgrade this from "the app is dead" to
"Claude Code retries".

Note my preload_entry_id is code_product_chunk, where @DrRIH's is
settings_panel_claude_code — so it isn't confined to one preload entry either.

5. Some things that came back clean

In case they save anyone else the time:

• Cache is structurally intact — blockfile magics correct, file sizes exactly

8192 + entry_size * max_entries, updating=0, crash=0; Simple Cache entries untruncated
with valid EOF records at filesize-24. Nothing is corrupt.

• All 233 modules in the failing chunk's transitive import closure are present in the

cache and decompress to valid JavaScript. Nothing missing anywhere in the graph.

• No service worker; no compression-dictionary transport (empty store, no dictionary headers);

no V8 code-cache entry for the failing URL at all.

• No 4xx/5xx on any app asset; no Crashpad minidump; no renderer-crash breadcrumb; and **zero

[error] lines in the main process** during either failure.

• cf52a4cc1 failed for me across three different content hashes (B8jZzds_, Du-DgKmH,

MgpW7IO9) on one machine across three web commits — consistent with @DrRIH's cross-report
observation that the chunk ids recur while the content hashes change.

Two things I could not explain:

• The plain URL is fetched and cached as a clean HTTP/1.1 200 by the *same Electron

instance* three seconds before the import of that same URL fails. Reproduced in both my
incidents (22:31:18 / 22:31:21, and 00:12:35 / 00:12:38).

• A month-old cache breaks a URL that did not exist when that cache was captured, so it

isn't a poisoned entry for the failing asset.

One possible reading of the first: a module map records failures, so once the idle preload's
import() rejects for that URL, later imports in the same realm reject immediately without
re-fetching, while fetch() ignores the module map entirely and still returns 200. That
matches the ordering, though not why the initial preload fails, nor why it survives reloads.

DevTools is disabled in the production build so I couldn't read the underlying net error. With
a dev build and the repro above it should show up in the Network panel quickly.

Happy to supply logs. I'd rather not attach the cache itself - it contains real file contents
and artifact bodies.