claude-code - 💡(How to fix) Fix [BUG] MSIX auto-update mid-session: AppContainer Job race breaks launch AND orphans the in-flight conversation (two-bug cascade, both with working fixes)

Preflight Checklist

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

What's Wrong?

Microsoft Store auto-updates of Claude Desktop (MSIX/Store distribution) force-close the running app mid-session — including while CCD (Claude Code Desktop) is doing agentic work in the background — then leave the app in an unrecoverable state via TWO cascading bugs:

Failure Mode 1 (launch failure): the new package version fails to relaunch. Windows shows a truncated, non-selectable error dialog. The full error from Microsoft-Windows-AppModel-Runtime/Admin is 0x80070020 — Cannot create the Desktop AppX container for package Claude_<version>_x64__pzs8sxrjxfjjc because an error was encountered converting the job. This is a kernel-side AppContainer / Job Object naming race during the in-place MSIX upgrade: the old version's Job Object hasn't released by the time the new version tries to spin up its own.

Failure Mode 2 (orphaned conversation): after Failure Mode 1 is worked around and Desktop relaunches, the specific conversation that was active at upgrade time shows "Remote Control disconnected / Your terminal's Claude Code session stopped responding" on every send, infinite reconnect loop. Other (new) conversations work fine. The conversation's history is visible (rendered from Anthropic's epitaxy backend), but the link between the epitaxy session ID and the local CCD session that owns the CLI subprocess is broken — Desktop never spawns the CLI when the conversation opens, no error is logged anywhere.

Recurring ~weekly for ~6 months. Until today the only known recovery was a full Windows reboot, which destroys not just the in-flight CC session but every other application open on the dev environment (IDEs, browser tabs, terminals, running games, other AI tools, MCP servers). This report includes working non-destructive fixes for both failure modes that aren't documented anywhere else — see the Additional Information section + the attached full report.

claude-desktop-update-stuck-bug.md

What Should Happen?

Auto-updates should NOT force-close Claude Desktop while a CCD session is active. The Microsoft Store auto-deployment should defer or prompt when the app is in active use.

If an update DOES proceed, the post-update relaunch should work cleanly without manual recovery steps, AND in-flight conversations should remain usable after the relaunch.

Currently neither holds:

• The update is uncancelable mid-session (no defer, no warning, no save-state prompt)
• The relaunch fails with 0x80070020, leaving Desktop unlaunchable until either a Windows reboot OR a Add-AppxPackage -Register recovery
• Even after Desktop relaunches, the conversation that was active at upgrade time is permanently orphaned and requires manually editing JSON files in %APPDATA%\Claude\ to recover

Error Messages/Logs

From Microsoft-Windows-AppModel-Runtime/Admin event log, fires twice per launch attempt after a failed upgrade:

Event ID 215:
0x80070020: Cannot create the Desktop AppX container for package
Claude_1.7196.0.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.

Event ID 208:
0x80070020: Cannot create the process for package
Claude_1.7196.0.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime.
[LaunchProcess]

0x80070020 = ERROR_SHARING_VIOLATION. "Converting the job" refers to the Win32 Job Object the AppX subsystem creates for Desktop-Bridge (Centennial) packaged apps.

Timeline of one failed upgrade (Microsoft-Windows-AppXDeploymentServer/Operational), all events 2026-05-17 07:27 local:
- 07:27:12  RegisterByPackageFamilyName started with ForceApplicationShutdownOption (NOT user-initiated)
- 07:27:42  TerminateSingleService for old CoworkVMService — result: 0x0 (success)
- 07:27:43  Old package state disabled; new package state disabled
- 07:27:44  Old install folder moved to WindowsApps\Deleted\Claude_<old>... — Result: 0x0
- 07:27:44  New version Deployment Register finished successfully (Event ID 400)
- 07:27:44  Package state set to enabled
- 07:27:44  Activation attempt fires 0x80070020 (Events 208 + 215)

The upgrade itself succeeds (package goes to Status: Ok, install folder in place, old version cleaned up). The failure happens immediately afterward when the system tries to ACTIVATE the freshly-registered package.

For Failure Mode 2: NO error is logged in main.log or claude.ai-web.log when the user opens the orphaned conversation. The log shows `[CCD] LocalSessions.setFocusedSession: sessionId=session_01<epitaxy-id>` and then 60+ seconds of nothing — no subprocess spawn attempt, no exception.

Steps to Reproduce

Reproduction requires the timing of an actual MSIX upgrade. The bug fires reliably whenever the Microsoft Store auto-deploys a Claude Desktop in-place upgrade while the app is running. Steps:

1. Have Claude Desktop installed via Microsoft Store / MSIX (NOT the Squirrel installer — different distribution).
2. Have Claude Desktop running with at least one active CCD (Claude Code Desktop) session — e.g. a coding conversation that has the local CLI subprocess attached.
3. Wait for Microsoft Store to push a new version of Claude Desktop (currently roughly weekly cadence; verified two upgrades within 4 days on the reporting machine: 1.6259.1 → 1.6608.2 on 2026-05-13, then 1.6608.2 → 1.7196.0 on 2026-05-17).
4. The Store auto-deploys the upgrade. Desktop is force-closed mid-session. The CCD subprocess is killed.
5. Click Claude Desktop in Start Menu / taskbar → Windows shows a truncated error dialog. The dialog text is non-selectable; the full error is only visible in Event Viewer (see Error Messages section).
6. Confirm via Get-AppxPackage Claude that the package is Status: Ok and at the new version. Confirm via openfiles /query /v | findstr /i claude that no actual file locks exist.
7. (Workaround) Run Get-AppxPackage Claude | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml" } — no admin needed, ~5 seconds, preserves user data. Desktop now launches.
8. Open the conversation that was active at upgrade time. Sidebar history displays correctly (rendered from server). Send a prompt → "Remote Control disconnected / Your terminal's Claude Code session stopped responding" appears. Retry button loops. A brand-new conversation on the same cwd works fine — definitive signal that the breakage is per-conversation, not global.
9. (Workaround for FM2) Start a fresh chat in Desktop, close Desktop, edit the new chat's local_*.json in %APPDATA%\Claude\claude-code-sessions\<account>\<org>\ to change its cliSessionId to the orphaned session's UUID, reopen Desktop. Full prior conversation context restored.

See attached full report for the complete diagnostic.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Frequency: yes (verifiable from Windows boot history). Bug existence in earlier MSIX versions vs newer: present throughout, but recurrence rate has accelerated. This user has ONLY ever used the MSIX / Microsoft Store distribution of Claude Desktop. All installs sourced from anthropic.com's "Claude Setup.exe" stub installer, which is a ~6 MB MSIX bootstrapper that installs the Store-distributed package on first run (not a self-contained installer — too small to bundle Electron / Node runtime / Claude assets, and the resulting install lands in the WindowsApps directory like every other MSIX package). No experience with any Squirrel-installer variant of Claude Desktop, so cannot speak to whether this bug class is MSIX-specific or shared across distributions. What IS verifiable as a regression is the FREQUENCY of recurrence. Forced-reboot cadence on this machine (from System log Event ID 6005) has tightened from ~21–45 days between reboots in Sep–Nov 2025 to ~5–8 days in Feb–May 2026 — consistent with Anthropic's Desktop release cadence accelerating significantly in recent months. Two upgrades fired within 4 days on this machine this week alone (1.6259.1 → 1.6608.2 on 2026-05-13, then 1.6608.2 → 1.7196.0 on 2026-05-17). Each tightening of update cadence directly multiplies the rate of session destruction for users running Claude Desktop continuously. None. The bug class has been present on every MSIX version of Claude Desktop this user has run (~6 months of continuous use). What HAS changed over that period is the frequency of recurrence (see "Is this a regression" above). Specific MSIX versions observed exhibiting this bug on this machine (the ones we have log evidence for in the current event log retention window; older versions have aged out): - 1.6259.1.0 - 1.6608.2.0 - 1.7196.0.0 (current)

Claude Code Version

2.1.143 (Claude Code) Note: the bug is in Claude Desktop's CCD wrapper around the CLI, not the CLI itself. The CLI version is provided because Desktop spawns it as a subprocess.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Terminal/Shell

Not applicable — this is a Claude Desktop GUI bug, not a terminal/CLI usage issue. The CLI subprocess Desktop spawns is invisible to the user.

Key prior-art notes for triage:

• #57221 (closed as duplicate) identified the CoworkVMService + MSIX Job Object root-cause class. This report adds the Add-AppxPackage -Register non-destructive recovery (not in #57221 or any other thread).
• #53717 (open) has the closest surface-symptom match for Failure Mode 2 (sidebar shows session but interacting fails) but the mechanism is opposite (their JSONL is empty stubs; mine is 19.96 MB / 7,271 entries intact, with the epitaxy↔local link being what's broken).

Diagnostic was performed collaboratively in a Claude Code session. Reporter contributed the 6-month recurrence pattern, environment context, and several wrong-hypothesis rejections. Claude Code contributed systematic walks of Windows event logs (AppModel-Runtime, AppXDeploymentServer, Application, System), MSIX package state inspection, Desktop's Sentry breadcrumbs and main.log / claude.ai-web.log analysis, and discovery of the claude-code-sessions\local_*.json epitaxy↔local-CCD link mechanism.

Cost-per-incident on this user's machine: every reboot loses ~7 days of accumulated Windows session state — multiple IDE windows with unsaved buffers, other AI coding tools (Codex, additional CC sessions, MCP servers), file explorer state, browser tabs, terminals with mid-execution work, running games and unsaved progress. With ~weekly recurrence, that's a substantial amount of work churned by Anthropic's update mechanism without user control.