[BUG] Windows MSIX: Stale LevelDB + agent-mode LOCK files permanently block Desktop startup (no recovery path)

Preflight Checklist

• [x] I have searched existing issues and found related reports (linked below)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Desktop (Windows MSIX/Store, v1.569.0.0) becomes permanently unable to start after a crash or unclean shutdown. A Windows system error — "Another program is currently using this file" — blocks launch with no recovery path. The user must perform extensive manual intervention (killing services, deleting lock files, resetting the MSIX package) to use the app again. Standard troubleshooting (removing lock files, killing zombie processes) is insufficient — the root cause is deeper than stale LevelDB locks.

Root Cause Analysis (Multi-Layer)

This is not a single lock file issue. There are three independent locking layers that all fail to recover from a crash:

Layer 1: LevelDB LOCK Files (Chromium/Electron)

After a crash, 6 LevelDB LOCK files persist in the MSIX sandboxed data directory:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\
├── IndexedDB/https_claude.ai_0.indexeddb.leveldb/LOCK
├── Local Storage/leveldb/LOCK
├── Session Storage/LOCK
├── shared_proto_db/LOCK
├── shared_proto_db/metadata/LOCK
└── VideoDecodeStats/LOCK

Additionally, a directory-based lock (empty directory used as a mutex):

└── local-agent-mode-sessions/…/.claude.json.lock   ← empty directory, not a file

And an MSIX settings lock:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\Settings\roaming.lock

No PID is stored in any of these locks. No liveness check is performed on startup. No timeout or recovery path exists.

Layer 2: Zombie claude.exe Processes

After the crash, two zombie claude.exe processes remained running (observed PIDs 3584, 195392). These held open handles on the lock files. However, killing them is dangerous: running taskkill /f /im claude.exe also kills Claude Code CLI sessions (same executable name), leaving the user with no Claude interface at all. PID-targeted killing is required but the app provides no tooling for this.

Layer 3: CoworkVMService Crash Loop (THE ACTUAL BLOCKER)

This is the critical finding. Even after removing all lock files and killing all zombie processes, the Desktop app still cannot start. The executable Claude.exe itself is locked at the OS level:

Program 'Claude.exe' failed to run: The process cannot access the file
because it is being used by another process

The cause: CoworkVMService is a Windows Service (StartType: Automatic) that runs cowork-svc.exe from inside the MSIX package directory:

C:\Program Files\WindowsApps\Claude_1.569.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

After a Desktop crash, this service enters a crash loop — starting and stopping every ~30 seconds. Each cycle re-locks files in the MSIX package directory. Because it is configured as Automatic with recovery options, it cannot be permanently stopped without admin elevation. It also cannot be disabled without admin (Set-Service returns "Access is denied").

The MSIX -ForceApplicationShutdown flag does not affect this service because it runs in Session 0 (services), not the user's session. Re-registering the MSIX package via Add-AppxPackage -Register -ForceApplicationShutdown does not stop it either.

What Was Required to Fix

Removing lock files was not enough. Killing zombie processes was not enough. Stopping CoworkVMService was not enough (it respawns). The only thing that worked was:

Get-AppxPackage -Name 'Claude' | Reset-AppxPackage

This nuclear option resets all app state — the user loses all local Desktop app data, sessions, settings, etc. This is an unacceptable recovery path for a crash.

Steps to Reproduce

1. Open Claude Desktop (Windows MSIX/Store version)
2. Force-kill the process (Task Manager → End Task, or trigger a crash during update/relaunch)
3. Attempt to relaunch Claude Desktop
4. Result: Windows system error "Another program is currently using this file" — app will not start
5. Removing lock files: does not fix
6. Killing zombie claude.exe: does not fix (and kills CLI sessions as a side effect)
7. Stopping CoworkVMService: does not fix (respawns automatically)
8. Only Reset-AppxPackage fixes it — but destroys all user data

What Should Happen

1. PID-based lock recovery: Every lock file (LevelDB, agent-mode, settings) should store the owning PID. On startup, check if the PID is alive. If dead, reclaim the lock automatically.

1. CoworkVMService crash resilience: The service should not hold handles that prevent the parent app from starting. Either:

• Run cowork-svc.exe from a location outside the MSIX package directory
• Release MSIX package handles when the Desktop app is not running
• Detect that the Desktop app has crashed and enter a dormant state instead of crash-looping

1. Graceful degradation: If lock acquisition fails, show an actionable dialog ("A previous session left stale locks. Clean up and restart?") — not a dead-end Windows error modal.

1. Safe process identification: Provide a way to kill Desktop-specific processes without also killing CLI sessions. Different executable names, a PID file, or a named mutex would all work.

1. No Reset-AppxPackage should ever be required: A crash should never put the app into a state where the only recovery destroys user data.

Workaround

The only reliable workaround is a full MSIX package reset (destroys all app data):

Get-AppxPackage -Name 'Claude' | Reset-AppxPackage

Partial workarounds that are insufficient on their own:

# Kill zombie processes BY PID (check Task Manager) — do NOT use /im claude.exe
taskkill /f /pid <Desktop_PID>

# Remove all lock files
Get-ChildItem -Path "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Include "LOCK","*.lock" | Remove-Item -Force -Recurse

# Stop CoworkVMService (will respawn unless disabled with admin)
Stop-Service CoworkVMService -Force
# Requires admin: Set-Service CoworkVMService -StartupType Disabled

Related Issues

• #22166 — Identical root cause on macOS (history.jsonl.lock directory, no PID-based recovery). Was tagged high-priority, closed as stale without a fix. This is the same unfixed bug class now manifesting on Windows with additional complications from CoworkVMService.
• #42776 — Same Windows bug filed today, tagged invalid without investigation.
• #41743 — Same bug triggered by updates. 1 "me too" comment. No Anthropic response.
• #42756 — Zombie claude.exe processes (macOS).
• #36204 — Zombie processes accumulating after CLI exit (macOS).

Environment

• OS: Windows 11 Pro N (10.0.26200)
• Claude Desktop: v1.569.0.0 (MSIX/Microsoft Store, package family Claude_pzs8sxrjxfjjc)
• Claude Code CLI: v2.1.91

Timeline of Troubleshooting

1. Desktop crashed with "Another program is currently using this file" modal
2. Found 2 zombie claude.exe processes (PIDs 3584, 195392) and 8 stale lock files
3. taskkill /im claude.exe killed zombies and the CLI session (same exe name) — total loss of Claude interface
4. New CLI session: removed all 8 lock files — app still won't start
5. Discovered CoworkVMService (cowork-svc.exe) crash-looping from inside MSIX package dir, re-locking files
6. Stopped service — respawns automatically. Cannot disable without admin.
7. Re-registered MSIX package (Add-AppxPackage -Register -ForceApplicationShutdown) — still won't start
8. Reset-AppxPackage — finally works, but destroys all app data