[BUG] Claude Desktop Windows: every 1.52386.x auto-update fails to relaunch (0x80070002), only Reset recovers

# Claude Desktop (Windows MSIX) will not launch after a silent update: root-cause investigation

## Summary

- **Version boundary:** the Windows MSIX build of Claude Desktop updates itself silently when idle, quits, and relaunches. On this machine the four silent updates before 1.52386.x (1.32352.0, 1.46388.3, 1.46388.4, 1.49585.0) all relaunched in 8 to 41 seconds. **All three updates into 1.52386.x (1.52386.0, 1.52386.3, 1.52386.6) failed to relaunch**, and the app stayed unlaunchable for 1 to 12 hours.
- **Failure point:** Windows cannot create the app's container, so `Claude.exe` never runs and the app writes nothing to its log. `Microsoft-Windows-AppModel-Runtime/Admin` event 215: `0x80070002: Cannot create the Desktop AppX container for package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job`, followed by event 208 `[LaunchProcess]`. The first failure is the automatic relaunch, 0.2 s after package servicing re-enabled the package and before the Register operation reported finished.
- **Recovery:** reboot, Settings > Repair and `Add-AppxPackage -Register` do **not** clear it. Every launch attempt triggers another repair-registration and a `CoworkVMService` restart, and still fails. **Only Settings > Reset** (which wipes per-user package data) recovers.
- Setting `CoworkVMService` to Manual does not help. Every update, repair and reset reinstalls it as Automatic, and the identical service stop and restart sequence ran during the earlier updates that relaunched fine.
- **Related: #84792** reports the same `0x80070002` signature on 1.26832.0 and blames `chrome-native-host.exe` running from inside the package data store. That helper runs from the same place on this machine, but it ran through four updates that relaunched fine, launches failed after a reboot before Chrome restarted it, and Reset recovered the app while it was still running. Details in 3.7.

Full investigation below: timeline, event log excerpts, what was ruled out, confidence levels, and reproduction steps. Identifiers have been redacted.

---

Machine: Windows 11 (build 26200), Claude Desktop MSIX `Claude_pzs8sxrjxfjjc`
Investigated: 14 Sep 2026, read-only (no config changes, no Reset, backup untouched)
All times are local AEST (UTC+10). User paths are shortened to `C:\Users\` and user SIDs to ``.

---

## 1. Summary

- Claude Desktop failed to come back after **every one of its last three silent ("stealth") updates**: to 1.52386.0 (11 Sep), 1.52386.3 (12 Sep) and 1.52386.6 (14 Sep). The four stealth updates before that (1.32352.0, 1.46388.3, 1.46388.4, 1.49585.0) all relaunched within 8 to 41 seconds. **Proven** from the app's own log.
- On 14 Sep, where Windows still had the runtime log, the failure happens **inside Windows, before `Claude.exe` runs**: `AppModel-Runtime` event 215/208, `0x80070002: Cannot create the Desktop AppX container ... because an error was encountered converting the job`. The first failure is the automatic relaunch, 0.2 s after package servicing re-enabled the package and about 0.9 s before the Register operation reported finished. **Proven** (ordering). That this timing is the cause is **inferred**.
- Once it has failed, the bad state persists. It survives reboots, Settings > Repair, and repair-registrations. Only Settings > Reset (which deletes the per-user package data) clears it. **Proven** for 14 Sep, and consistent with 12 Sep.
- I did **not** find a malformed path or garbage value in the app's config files in the broken 12 Sep snapshot. Because `Claude.exe` never started during the outage, its JSON config cannot have been what blocked launch. **Proven negative** for app-level config. The exact per-user file that Windows fails on is **not identified** (see 3.7 for the `chrome-native-host.exe` theory from #84792 and why it does not fully fit here).
- `CoworkVMService` is **not** the distinguishing factor. The identical stop, reinstall and restart sequence, with the same warnings, ran during the successful 5 Sep and 9 Sep updates. On 14 Sep the first launch failure happened while the service was stopped. Setting it to Manual was **already reverted to Automatic** by the Reset (proven), and would be reverted by every update or repair.

---

## 2. Timeline

| Time (AEST) | Event | Source |
|---|---|---|
| 11 Sep 09:52 | Update to 1.52386.0 downloaded, registration deferred (app running) | main log, AppX 638 / 419 `0x80073D02` |
| 11 Sep 21:28:38 | Stealth update: app quits for update | main log |
| 11 Sep 21:28:45 | 1.52386.0 registered, service reinstalled | AppX 400, SCM 7045 |
| 11 Sep 21:28 to 12 Sep 09:14 | **No app start logged for 11 h 46 m** | main log |
| 11 Sep 23:56:42, 23:57:50 | Repair-registration and RepairPackageOperation on Claude; service crashes (7034) at 23:57:00 and 23:57:13 | AppX 603, SCM 7034 |
| 12 Sep 09:06, 09:11 | Two restarts (user, then Windows Update) | User32 1074 |
| 12 Sep 09:14:28 | App starts on 1.52386.0 (recovered **without** Reset) | main log |
| 12 Sep 09:15:40 | Update to 1.52386.3 downloaded | main log |
| 12 Sep 17:05:03 | Stealth update: quit, relaunch state saved | main log |
| 12 Sep 17:05:05 to 17:05:37 | RegisterByPackageFamilyName (ForceApplicationShutdown) of 1.52386.3 | AppX 603, 400 |
| 12 Sep 17:54:34 | Settings > Repair (RegisterByPackageFullName, RepairAppRegistration); service stop/reinstall loop every ~1.5 s | AppX 603, SCM 7040/7045 |
| 12 Sep 17:58:23 | `Add-AppxPackage -Register` / repair fails: `0x80073D02 Unable to install because the following apps need to be closed Claude_1.52386.3.0` | AppX 419/401/404 |
| 12 Sep 17:59:01 | Reboot | User32 1074 |
| 12 Sep 18:01:44 | Service crash | SCM 7034 |
| 12 Sep ~18:12 | Container copied to a backup folder (broken-state snapshot) | file times |
| 12 Sep 18:18:50 | Settings > Reset (deployment ops 2 and 11) | AppXDeployment 332 |
| 12 Sep 18:19:14 | App starts on 1.52386.3 | main log |
| 14 Sep 09:55:40 to 09:56:11 | Update to 1.52386.6 added, registration deferred (app running) | AppX 603/574/638/658/400 |
| 14 Sep 10:10:33 | Stealth update: quit | main log |
| 14 Sep 10:10:35.128 | RegisterByPackageFamilyName (ForceApplicationShutdown) | AppX 603 |
| 14 Sep 10:10:36.638 | CoworkVMService stopped | CoworkVMService, AppX 9650 |
| 14 Sep 10:10:38.455 | Servicing finished, package enabled | AppX 10007 |
| **14 Sep 10:10:38.665** | **First launch failure `0x80070002`** (automatic relaunch) | AppModel-Runtime 215 |
| 14 Sep 10:10:39.545 | CoworkVMService starting | CoworkVMService |
| 14 Sep 10:10:39.551 | Register operation reported finished | AppX 400 |
| 14 Sep 10:10:41.665 | Second failure, 215 + 208 `[LaunchProcess]` | AppModel-Runtime |
| 14 Sep 11:41:31 to 11:42:15 | User launch attempts: 113 x event 215, 55 x 208 (`0x80070002`), 5 x 208 (`0x80073D00`); each launch triggers a repair-register and a service restart | AppModel-Runtime, AppX, SCM |
| 14 Sep 13:25:16 | Reboot | User32 1074 |
| 14 Sep 13:24:39 to 13:28:49 | Launch still fails after reboot: 16 x 215, 8 x 208 | AppModel-Runtime |
| 14 Sep 13:28:15 | Repair-registration, succeeds, launch still fails | AppX 603/400 |
| 14 Sep 13:30:45 | Settings > Reset (`ResetPackageOperation`) | AppX 603 |
| 14 Sep 13:30:51 | Service start type changed **from demand start** to disabled, then reinstalled as auto start | SCM 7040, 7045 |
| 14 Sep 13:31:32 | App starts on 1.52386.6 | main log |

---

## 3. Findings and evidence

### 3.1 Only the 1.52386.x stealth updates failed to relaunch (Proven)

Parsed from every `main*.log` on the machine (`%LOCALAPPDATA%\Claude\Logs` and the older in-container copies):

| Stealth quit | Next "Starting app" | Gap | Version that started |
|---|---|---|---|
| 18 Aug 10:00:10 | 18 Aug 10:00:44 | 34 s | 1.32352.0 |
| 21 Aug 10:57:16 | not in surviving logs | unknown | log location changed at this update, older rotated logs lost |
| 5 Sep 09:12:17 | 5 Sep 09:12:54 | 37 s | 1.46388.3 |
| 5 Sep 17:48:30 | 5 Sep 17:48:38 | 8 s | 1.46388.4 |
| 9 Sep 11:51:01 | 9 Sep 11:51:42 | 41 s | 1.49585.0 |
| **11 Sep 21:28:38** | **12 Sep 09:14:28** | **11 h 46 m** | 1.52386.0 (after two reboots) |
| **12 Sep 17:05:03** | **12 Sep 18:19:14** | **1 h 14 m** | 1.52386.3 (after Reset) |
| **14 Sep 10:10:33** | **14 Sep 13:31:32** | **3 h 21 m** | 1.52386.6 (after Reset) |

The 11 Sep gap is very likely a third occurrence: there were repair operations on the package at 23:56 and 23:57 and two service crashes in the middle of it. I can't prove it was a launch failure, because the Windows runtime log for that night has rolled over (see 5.1).

Pattern of each stealth update in `main1.log`, identical all three times:

```
2026-09-14 10:10:33 [info] [stealth-update] Triggering stealth update after idle timeout
2026-09-14 10:10:33 [info] [stealth-relaunch] Saved z-order anchor: 0xd8008a (above our 0x750874)
2026-09-14 10:10:33 [info] [stealth-relaunch] Saved navigation history (50 entries, active=49)
2026-09-14 10:10:33 [info] [CCD] Killing 9 PTY process tree(s) on quit
2026-09-14 10:10:35 [info] beforeQuitForUpdate handler fired, going down for update
2026-09-14 10:10:35 [info] Windows session ending (close-app) - quitting the app
2026-09-14 13:31:32 [info] Starting app {
```

No line at all is written between the quit and the post-Reset start, on 12 Sep or 14 Sep. `Claude.exe` never reached its logger.

### 3.2 The failure is in Windows container creation, not in the app (Proven for 14 Sep)

`Microsoft-Windows-AppModel-Runtime/Admin`, 14 Sep, servicing and the relaunch interleaved (verbose AppX lines trimmed):

```
10:10:35.128 [603] AppXDeployment-Server: Started deployment RegisterByPackageFamilyName operation on a package with main parameter Claude_pzs8sxrjxfjjc and Options ForceApplicationShutdownOption
10:10:36.606 [217] AppModel-Runtime: Destroyed Desktop AppX container {89A1BFC9-...} for package Claude_1.52386.3.0_x64__pzs8sxrjxfjjc.
10:10:36.613 [9648] AppXDeployment-Server: TerminateSingleService for update successful for service Claude_1.52386.3.0_x64__pzs8sxrjxfjjc in package CoworkVMService
10:10:36.638 [1] CoworkVMService: Claude VM Service stopped.
10:10:36.701 [67] AppModel-Runtime: Failed with 0x5 modifying AppModel Runtime status for package Claude_1.52386.3.0_x64__pzs8sxrjxfjjc (current status = 0x280000, desired status = 0x480000).
10:10:37.010 [7045] Service Control Manager: A service was installed in the system. Service Name: Claude Service File Name: "C:\Program Files\WindowsApps\Claude_1.52386.6.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
10:10:37.155 [42] AppModel-Runtime: Successfully updated AppContainer Claude_pzs8sxrjxfjjc.
10:10:38.455 [10007] AppXDeployment-Server: Finished servicing singleton package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc. Setting the singleton package state to enabled returned with 0x0.
10:10:38.665 [215] AppModel-Runtime: 0x80070002: Cannot create the Desktop AppX container for package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
10:10:39.545 [1] CoworkVMService: Claude VM Service starting.
10:10:39.551 [400] AppXDeployment-Server: Deployment Register operation ... on Package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc from: (AppxManifest.xml) finished successfully.
10:10:41.665 [215] AppModel-Runtime: 0x80070002: Cannot create the Desktop AppX container for package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
10:10:41.665 [208] AppModel-Runtime: 0x80070002: Cannot create the process for package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]
```

Two details worth flagging:
- Event 67 at 10:10:36.701: Windows failed with `0x5` (access denied) while moving the **old** package's runtime status to `0x480000`. Nothing similar was visible in the successful update windows I checked, but the runtime log for those dates has rolled over, so I can't compare. **Unverified lead.**
- `0x80070002` is `ERROR_FILE_NOT_FOUND`. The same error repeats for every later launch until Reset.

### 3.3 Each launch attempt triggers a repair loop that restarts the service (Proven)

14 Sep, one second of the 11:41 attempts:

```
11:41:31.900 [215] AppModel-Runtime: 0x80070002: Cannot create the Desktop AppX container for package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
11:41:31.933 [208] AppModel-Runtime: 0x80070002: Cannot create the process for package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]
11:41:31.994 [603] AppXDeployment-Server: Started deployment RegisterByPackageFullName ... Options ForceTargetApplicationShutdownOption,RepairAppRegistrationOption
11:41:32.026 [649] AppXDeployment-Server: Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_1.52386.6.0_x64__pzs8sxrjxfjjc
11:41:32.863 [649] AppXDeployment-Server: ACLs repaired successfully ... Register next time should succeed.
11:41:32.897 [7040] Service Control Manager: The start type of the Claude service was changed from auto start to disabled.
11:41:33.012 [1] CoworkVMService: Claude VM Service stopped.
11:41:33.486 [1] CoworkVMService: Claude VM Service starting.
11:41:34.760 [603] AppXDeployment-Server: Started deployment RegisterByPackageFamilyName ... Options ForceTargetApplicationShutdownOption,SkipReregisterIfPackageStatusOk,ImmediatePriorityRequest
```

During these loops some launches return `0x80073D00` (`ERROR_PACKAGE_UPDATING`, "The application cannot be started because it is currently updating"). Between 17:54:35 and 18:01:50 on 12 Sep the same service reinstall loop ran dozens of times, with service crashes (7034) at 17:58:35, 17:58:47 and 18:01:44.

On 12 Sep, the repair attempt the user ran failed because Windows considered the package still running, although `Get-Process claude` showed no `Claude.exe` process at the time (the user's own check, not in any log):

```
17:58:24.395 [419] Error AppXDeployment-Server: error 0x80073D02: Unable to install because the following apps need to be closed Claude_1.52386.3.0_x64__pzs8sxrjxfjjc.
17:58:24.417 [401] Error AppXDeployment-Server: Deployment Register operation ... on Package Claude_1.52386.3.0_x64__pzs8sxrjxfjjc ... failed with error 0x80073D02.
```

Two processes tied to the package were alive then: `cowork-svc.exe` (a packaged service in the same package) and `chrome-native-host.exe` (started by Chrome from inside the package data store; its log shows it stopping at 17:59:03 for the reboot). Which one Windows counted as "in use" is **not determined**.

### 3.4 Reboot and Repair do not clear it; Reset does (Proven on 14 Sep)

- Reboot at 13:25:16. Launch failures continue at 13:24:39 to 13:28:49: 16 x event 215 and 8 x event 208, the later ones after the 13:26 boot.
- Repair-registration at 13:28:15 finishes successfully (AppX 400 at 13:28:16). The launch still fails at 13:28:49.
- `ResetPackageOperation` at 13:30:45. The app starts at 13:31:32 with no errors.

So the defect lives in state that Reset removes and Repair keeps: the per-user package data under `%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc` (LocalCache, Settings, SystemAppData registry hives) and its registration state.

### 3.5 The broken snapshot: what I compared and what I ruled out

The snapshot (`PackageData`, taken ~18:12 on 12 Sep, after the 17:59 reboot and before Reset) was compared with the working container.

**App config files: no malformed or empty path found (Proven negative).**
`claude_desktop_config.json`, `config.json`, `window-state.json`, `Preferences`, `Local State`, `bridge-state.json`, `git-worktrees.json` and `design` all parse as valid JSON. Their path values (`terminalCliPowerShellPath`, MCP server commands, trusted folders) all point at real paths. None contains non-ASCII or truncated strings. More importantly, `Claude.exe` never started during the outage (3.1), so nothing it reads at startup can have blocked process creation.

**`stealth-relaunch` (222 KB, written 12 Sep 17:05:03): present in snapshot, absent after Reset. Not the cause.**
It holds `ts`, `windowVisible`, `windowMinimized`, `zOrderAnchorHwnd` and 50 `navEntries` (`https://claude.ai/epitaxy/local_...` URLs plus Chromium page-state blobs). No paths or command lines. It is only read by the app's own startup code, which never ran. It remained because the relaunch never happened. It is a symptom, not a cause.

**`claude://` protocol handler in the package's virtual registry: stale version path, but not the cause.**
The snapshot's `SystemAppData\Helium\UserClasses.dat` has:

```
HKCU\Software\Classes\claude\shell\open\command = "C:\Program Files\WindowsApps\Claude_1.52386.0.0_x64__pzs8sxrjxfjjc\app\Claude.exe" "%1"
```

That path pins 1.52386.0.0, which was removed at 17:05:36 when 1.52386.3.0 registered. The same hive holds icon paths for about 20 removed versions. The live install currently points at 1.52386.6.0, so the app rewrites the handler on every start. A stale handler would break `claude://` links, not a Start-menu launch, which goes through the AUMID. **Worth fixing, not the root cause.**

**Registry hive checksums: not a signal.**
Both snapshot Helium hives (`User.dat`, `UserClasses.dat`) have matching sequence numbers but a base-block checksum that does not validate. A control run across other packaged apps on this machine found the same "bad" checksum on several working packaged apps' hives (including inbox Microsoft apps), so this is normal and I have discounted it.

**Container pollution: real, cause not shown.**
The snapshot container is 18.9 GB, 40,596 files. Besides Claude's own data it holds data from other programs started from Claude Code sessions: folders from a trading platform and its data add-on, Playwright, the npm cache and Wrangler, and a 4.7 MB virtual `User.dat` containing keys from a browser, a cloud-sync client, an office suite and the trading platform. Child processes of an MSIX app inherit its file and registry virtualisation. This makes the per-user package data unusually large and busy, but I have no evidence tying it to `0x80070002`.

### 3.6 The error dialog (Inferred)

The user saw a dialog titled with the `Claude.exe` path: "Windows cannot find ''. Make sure you've typed the name correctly", with different garbage characters each attempt. It also once said "Another program is currently using this file".

- "Windows cannot find" is the shell's standard text for `ERROR_FILE_NOT_FOUND`, which matches the `0x80070002` activation failure logged for every launch. Strongly consistent, but the dialog itself is not in any log.
- The name changing each time suggests the shell formats the message with a string that was never filled in because activation failed early. That is a presentation bug on top of the real failure, and I cannot prove it from here.
- "Another program is currently using this file" is consistent with the `0x80073D00` / `0x80073D02` in-use errors logged during the repair loops.

### 3.7 Relation to #84792 (`chrome-native-host.exe` in the package data store)

#84792 attributes the same `0x80070002` failure to the Claude in Chrome native messaging host, which Chrome launches from inside the package data store and which therefore outlives the app's quit for update. That setup is present here:

```
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension
(Default) = C:\Users\\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json

chrome-native-host.exe started 14 Sep 13:28:29, still running
C:\Users\\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe
```

Three observations from `%LOCALAPPDATA%\Claude\Logs\chrome-native-host.log` and the event logs that do not fit it being the sole cause on this machine:

1. **It was running during the successful updates too.** Its last start before 12 Sep was 3 Sep 13:09:10, with no stop logged until 12 Sep 09:06:59. So it was up through the 5 Sep (twice) and 9 Sep stealth updates, which relaunched in 8 to 41 s, as well as the failed 11 Sep update. It was also running at the failed 12 Sep update (started 09:14:49) and 14 Sep update (started 12 Sep 19:01:19).
2. **Launch failed after a reboot, before Chrome restarted it.** On 14 Sep the native host stopped at 13:25:18 for the reboot, the OS started at 13:26:00, launches failed with events 215/208 at **13:28:14** and **13:28:17**, and the native host did not start again until **13:28:29**.
3. **Reset recovered the app while it was still running.** `ResetPackageOperation` ran at 13:30:45 and the app started at 13:31:32, while the native host process started at 13:28:29 kept running from the package data store (it is still running hours later).

It may still contribute: it was holding the store at every failure, and the 12 Sep morning recovery happened with the app launched at 09:14:28, before the native host restarted at 09:14:49. But on this machine it is neither sufficient (four clean updates with it running) nor required for the broken state to persist (failures at 13:28:14 and 13:28:17). Caveat: the log records process start and stop, not the path it ran from on earlier dates; the registry path above is its current location.

---

## 4. CoworkVMService and setting it to Manual

**Proven:**
- `CoworkVMService` is a packaged service (`TYPE 210 WIN32_PACKAGED_PROCESS`) declared in the MSIX manifest. Every register, repair, update and reset deletes and reinstalls it from the manifest as **auto start** (SCM 7040 then 7045 "Service Start Type: auto start").
- The Manual setting (`Start = 3`) was in place at 13:30:51 on 14 Sep (7040 "changed from demand start to disabled") and was immediately replaced by the Reset. At 15:36 today, `sc qc CoworkVMService` shows `START_TYPE: 2 AUTO_START`, state `RUNNING`, and the registry has `Start = 2`. **The Manual setting is not in effect now.**
- The service logs these warnings on every stop and start, including the successful 5 Sep and 9 Sep updates:
```
Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing: open service: Access is denied.
Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied.
```

**Why it is not the distinguishing cause:**
- On 5 Sep 17:48 and 9 Sep 11:51 the identical 7040, 7045, "stopped", "starting" sequence and both warnings occurred, and the app relaunched in 8 s and 41 s.
- On 14 Sep the first failure (10:10:38.665) happened while the service was stopped (stopped 10:10:36.638, starting 10:10:39.545).

**Assessment:**
- Manual does not persist. The operations that trigger the bug (update, repair, reset) all reinstall the service as Automatic.
- Even if it did persist, the evidence says the service is not needed for the failure to occur.
- The service may still add to the problem: the in-use errors on 12 Sep and the crash and restart loops during repair. So it may make recovery harder without being the root cause. Setting it to Manual is harmless but should not be treated as a fix.
- I found no user-side setting that reliably prevents this. Stopping the app's idle-time stealth update from running is the most direct lever, and I found no user-facing setting for it. What is needed is a fix in the updater's relaunch path (section 7).

---

## 5. Confidence and gaps

| Claim | Status |
|---|---|
| All three 1.52386.x stealth updates failed to relaunch; the four before them succeeded | **Proven** (app log) |
| 14 Sep: launch failed at Windows container creation, `0x80070002`, before `Claude.exe` ran | **Proven** (AppModel-Runtime 215/208, no app log lines) |
| 14 Sep: first failure was the automatic relaunch, 0.2 s after package re-enabled and before Register finished | **Proven** (ordering) |
| The relaunch racing the end of servicing is what leaves the bad state | **Inferred** |
| 12 Sep failed the same way at the Windows level | **Inferred** (same app-log signature, same repair loop and in-use errors; runtime log for 12 Sep no longer exists) |
| 11 Sep overnight was a third occurrence | **Probable** (11 h 46 m gap, repair ops, service crashes; no runtime log) |
| Reboot and Repair do not clear it; Reset does | **Proven** 14 Sep; consistent 12 Sep |
| App JSON config and `stealth-relaunch` are not the launch blocker | **Proven negative** (app never started) |
| Exact per-user file or state Windows fails on | **Not identified** |
| Garbled dialog text is the shell rendering the `0x80070002` failure | **Inferred** |
| CoworkVMService is not the distinguishing trigger | **Strongly supported** (control updates, failure while stopped) |
| Manual start type is overwritten by update, repair and reset | **Proven** |
| Access-denied event 67 on the old package status change is related | **Unverified lead** |
| `chrome-native-host.exe` in the package data store (#84792) is sufficient to cause this | **Contradicted here** (running during four clean updates) |
| It is required for the broken state to persist | **Contradicted here** (failures at 13:28:14 and 13:28:17, before it restarted at 13:28:29) |

### 5.1 Evidence that no longer exists

- `Microsoft-Windows-AppModel-Runtime/Admin` is capped at about 1 MB (`maxSize: 1052672`). Its oldest surviving event is 13 Sep 20:07:22, so the 11 and 12 Sep launch failures are gone. The 14 Sep failure generated nearly 200 events in under 3 hours.
- The 14 Sep broken container was not captured before Reset.
- App logs before about 6 Sep have rotated. The logs also moved from the container to `%LOCALAPPDATA%\Claude\Logs` at the 21 Aug update, so that update's relaunch cannot be checked.
- `C:\ProgramData\Claude\Logs\cowork-service.log` has no entries for either failure window (no non-debug lines 12 Sep 17:00 to 18:25 or 14 Sep 09:40 to 13:40).

---

## 6. Reproduction sequence (observed on this machine, not yet reproduced on a clean one)

1. Install Claude Desktop MSIX at 1.49585.0 or any 1.52386.x build. Leave `CoworkVMService` at its default.
2. Keep the app running and signed in. The updater downloads the next build, and Windows stages it with `DeferRegistrationWhenPackagesAreInUse` (AppX 638 "Packages were not updated because affected apps are still running", 658 "Marking package ... for deferred registration").
3. Leave the app idle until the log shows `[stealth-update] Triggering stealth update after idle timeout`.
4. The app quits (`beforeQuitForUpdate`), and `RegisterByPackageFamilyName` runs with `ForceApplicationShutdownOption`. Servicing terminates `CoworkVMService`, reinstalls it and re-enables the package.
5. The automatic relaunch fires right after event 10007 "Finished servicing singleton package", before AppX 400 "finished successfully".
6. Expected failure: `AppModel-Runtime` 215 `0x80070002 ... converting the job`, then 208 `[LaunchProcess]`. No window appears and nothing is written to `main.log`.
7. Launch from Start: "Windows cannot find ''". Each attempt triggers a repair-register and a service restart (7040/7045), and some attempts return `0x80073D00`.
8. Reboot, Settings > Repair, and `Add-AppxPackage -Register` do not recover it (the last may fail with `0x80073D02` while `cowork-svc.exe` is running). Settings > Reset recovers it immediately.

Hit rate on this machine: 3 of 3 stealth updates into the 1.52386.x line failed. 4 of 4 earlier stealth updates succeeded.

---

## 7. Suggested areas for Anthropic to look at

1. **Relaunch timing after self-update.** Wait for the Register operation to complete (for example, the deployment async result, or package status reporting OK) before activating the app again. Retry with backoff on `0x80073D00` or `0x80070002` rather than leaving the package in a failed state. Check what changed in the relaunch path between 1.49585.0 and 1.52386.0.
2. **What per-user state a failed Desktop AppX container creation leaves behind**, such that Repair and reboot cannot clear it but Reset can. The 12 Sep `PackageData` snapshot is available if a copy would help. It is 18.9 GB and contains personal data, so it would need to be shared privately.
3. **CoworkVMService SCM recovery configuration.** Every start and stop logs `open service: Access is denied`, so the service cannot disarm its own recovery actions during servicing, which its own warning says can auto-restart it mid-update. It also appears to hold the package "in use" (`0x80073D02`) when no app window is running.
4. **`claude://` handler pinned to a versioned `WindowsApps` path** in the package's virtual `HKCU\Software\Classes`. It goes stale after each update until the app next starts.
5. **Container virtualisation for child processes.** Tools launched from Claude Code sessions (a trading platform, npm, Wrangler, Playwright, a browser, an office suite) write into the Claude package container and its virtual registry, growing it to about 19 GB.
6. **Native messaging host location.** Chrome launches `chrome-native-host.exe` from inside the package data store (`LocalCache\Roaming\Claude\ChromeNativeHost`), so a Chrome-owned process lives in the package profile across updates and even a Reset. Even though it does not explain the failures here on its own, moving it outside the package store (as #84792 suggests) removes one variable.

---

## 8. If it happens again: capture before Reset

In this order, before clicking Reset:

1. Export the runtime log straight away, before it rolls over:
`wevtutil epl Microsoft-Windows-AppModel-Runtime/Admin %USERPROFILE%\Desktop\appmodel-runtime.evtx`
2. Also export `Microsoft-Windows-AppXDeploymentServer/Operational`, `System` and `Application` the same way.
3. Copy `%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc` (this is what the 12 Sep snapshot did).
4. Copy `%LOCALAPPDATA%\Claude\Logs`.
5. Record `sc qc CoworkVMService`, `sc query CoworkVMService` and `Get-AppxPackage Claude`.
6. Then Reset.

Optional, a system change, so the owner decides: raising the AppModel-Runtime log size (`wevtutil sl Microsoft-Windows-AppModel-Runtime/Admin /ms:20971520`) would keep several days of launch failures instead of about one.

---

## Related

- #84792: same `0x80070002` signature (1.26832.0), `chrome-native-host.exe` theory, see 3.7
- #76357: update fails with "Another program is currently using this file"; lingering `Claude.exe` / `CoworkVMService` locks, reboot recovers
- #92167, #89680, #91763, #73107: `0x80070020` variant where orphaned processes pin the old container and a reboot recovers
- #84435, #81267: `CoworkVMService` and package servicing with `0x80073D02`

Start with the logs under %LOCALAPPDATA%\Claude\Logs and the Microsoft-Windows-AppModel-Runtime/Admin, AppX, AppXDeployment-Server, and Service Control Manager events cited in the report. Compare the successful pre-1.52386.x updates with a failing 1.52386.x silent update, including the automatic relaunch and Reset recovery. Done means identifying the Windows package-data or registration condition causing 0x80070002 and confirming the failure no longer occurs.

Escrito por el modelo de indexación a partir del texto del issue.