[Bug] MSIX auto-update leaves package in unlaunchable state: 0x80070020 container creation failure

I hit what looks like the same underlying issue, on a different machine (Windows 10 Pro 19045, x64, corporate-managed), and can add a data point about what happens after fully removing the stuck MSIX package — since this report describes the state with the package still present.

Same starting point:

• Same package version: Claude_1.40609.1.0_x64__pzs8sxrjxfjjc
• Same suspect: CoworkVMService (declared via windows.service extension, LocalSystem) still holding a container/registration for that package while the user-session app can't launch. In my case sc.exe qc CoworkVMService showed BINARY_PATH_NAME still pointing at that old package path even after later reinstall attempts.
• Same original trigger: a stealth/background auto-update (in my case landing 1.44121.1) that first surfaced as a narrower failure — a new "pre-traversal probe" doing scandir on %APPDATA%\Claude (bind-mapped via bindflt into the package container) before writing, throwing PlantDetectedError: Unreadable component during pre-traversal probe and failing WSL deploys with DeployError ... artifact: "cli archive". Full launch failure came later.

What I additionally tried — full removal, not just stop/re-register:

1. Uninstalled the MSIX package completely via Settings > Apps.
2. Confirmed removal with Get-AppxPackage *Claude* returning no results (not just Status≠Ok — the package was fully gone).
3. Downloaded a fresh installer from claude.com/download and reinstalled.
4. App still fails to launch, same generic "Check for updates and try again..." message — this time with no MSIX package present on the system at all.

The .err log this time points to a different, earlier crash than the container error in this report:

Error: Failed to get 'logs' path
    at Object.<anonymous> (app://\.vite\build\index.pre.js:1:841662)
    ...
    at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:169:5)
    at node:internal/main/run_main_module:33:47

This crashes on app.getPath('logs') during startup, before any window opens — so either a full clean reinstall doesn't fully reset whatever state is involved (registry, some other leftover under %APPDATA%/%LOCALAPPDATA%, etc.), or this is a related-but-distinct bug that produces the same generic error message.

Happy to attach a redacted diagnostic bundle (system info, main.log, reachability, MCP logs) if useful — can also provide un-redacted values privately via a support ticket if that's a faster path for someone with access to internal tooling.

Confirmed workaround (same as this report's context): running the Claude Code CLI directly inside WSL, bypassing Claude Desktop entirely, works normally — tested end-to-end (binary runs, /login works, prompts get normal responses).

I'm experiencing the same issue with Claude Desktop on Windows. Claude suddenly closes, and reopening it gives "Another program is currently using this file."

Event Viewer consistently shows 0x80070020 (Events 215/208): "Cannot create the Desktop AppX container... error encountered converting the job."

I tested with CoworkVMService stopped, all Claude/Claude Code processes terminated, and no Claude-related handles found in Process Explorer. The issue still occurs. Get-AppxPackage also shows only one correctly registered Claude package.

Restarting Windows fixes it temporarily, but the issue eventually returns.

-------------------------------------------------------------------------------------------------------------------

Estoy experimentando el mismo problema con Claude Desktop en Windows. Claude se cierra repentinamente y, al intentar abrirlo de nuevo, aparece «Otro programa está utilizando este archivo».

El Visor de eventos muestra de forma consistente el error 0x80070020 (eventos 215/208): «Cannot create the Desktop AppX container... error encountered converting the job.»

He probado con CoworkVMService detenido, todos los procesos de Claude/Claude Code finalizados y sin ningún handle relacionado con Claude detectado mediante Process Explorer. El problema persiste. Get-AppxPackage también muestra un único paquete de Claude correctamente registrado.

Reiniciar Windows lo soluciona temporalmente, pero el problema acaba volviendo.

Hitting this too, twice now, on a personal machine rather than a managed corporate image — so it is not specific to your team's build. Still reproducing on current versions, two weeks after this was filed.

Environment: Windows 11 Home, build 26200 (you are on 11 Pro, same build). MSIX install, package family Claude_pzs8sxrjxfjjc.

| | Occurrence 1 | Occurrence 2 |
|---|---|---|
| Date | 2026-09-11 | 2026-09-18 |
| App | 1.49585.0 → 1.52386.0 | 2.110.0 → 2.2553.1 |
| CLI | 2.1.260 → 2.1.266 | 2.1.271 → 2.1.275 |
| Downtime | ~70 min, 9 launch attempts | ~2 min, 2 launch attempts |

Two stealth updates out of two ended this way. Both times the trigger was the idle-timeout updater, not a manual update.

The app's own log ends at the update quit:

[stealth-update] Triggering stealth update after idle timeout
beforeQuitForUpdate handler fired, going down for update
Windows session ending (close-app) - quitting the app

and then contains nothing at all until the first successful start after a reboot — the process never reaches any of its own code. Meanwhile Microsoft-Windows-AppModel-Runtime/Admin shows the same four events in both occurrences:

Event 68   AppModel Runtime status for package Claude_<old> successfully updated to 0x280000 (previous = 0x200000)
Event 67   Failed with 0x5 modifying AppModel Runtime status for package Claude_<old> (current = 0x280000, desired = 0x480000)
Event 215  0x80070020: Cannot create the Desktop AppX container for package Claude_<new> because an error was encountered converting the job.
Event 208  0x80070020: Cannot create the process for package Claude_<new> because an error was encountered while configuring runtime. [LaunchProcess]

Worth noting the ordering, which is identical in both incidents: the 0x5 (access denied) on the outgoing package comes first, one second before the 0x80070020 on the incoming one. The old package's runtime status cannot be moved to 0x480000, and only then does the container for the new package fail. That reads less like a file lock and more like the old package never fully releasing its runtime state — consistent with your silo hypothesis.

Two more data points:

• CoworkVMService is healthy throughout. Its log shows the service starting, verifying its signature and listening on its pipe on every attempt; what never appears is [Server] Client connected, because the app side never launches. It only connects after a reboot. So the service is not crashed — it is simply the only half of the package that gets a container.
• Every failed launch is visible in Microsoft-Windows-TWinUI/Operational as event 1621 with result 7. In occurrence 1 the Service Control Manager additionally logged 7034 (service terminated unexpectedly) three times across the 70 minutes of retries.

A reboot fixes it immediately and reliably — confirmed twice. That is the one workaround I can confirm works, and it is worth adding to the issue since none of the lighter ones do. I have not tested sign-out / sign-in; if someone hits this and tries that first, it would be useful to know, since it would narrow the leak down to per-session job objects rather than machine-wide state.

From a user's point of view the bad part is the trigger: the updater fires on idle, so the app breaks itself while unattended, and what you come back to is a Windows sharing-violation dialog rather than anything pointing at the update. The first time, it cost me an hour before I found the AppModel-Runtime events.