You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] Windows/MSIX: git fsmonitor--daemon spawned by Claude Code inherits the AppX container job, survives the update's forced shutdown, and blocks relaunch of the new version (0x80070020). Root cause + no-reboot workaround #91763
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?
After the Claude Desktop auto-updater stages a new MSIX version and force-relaunches the app, every subsequent launch fails with the dialog "Another program is currently using this file" (HRESULT 0x80070020, AppModel-Runtime events 215/208). This symptom is already reported in #53247, #73107, #87879, #89680, #89687, #89912, #90269, #91482, #91736 and #91749, with the cause variously attributed to a race, cowork-svc.exe, an orphaned silo, or an unidentified leaked job object.
#73107 identified the correct mechanism (an orphaned Claude Code child process pinning the old version's container) with an elevated culprit (llama-svc.exe -elevated). This report shows the same mechanism with a far more common, entirely non-elevated culprit that will hit any Windows developer using git, and gives a no-reboot, no-elevation workaround. Reproduced three times in 24 hours across three consecutive updates (1.40609.1 → 1.44121.1 → 1.44121.2 → 1.44121.4).
The old version's Desktop AppX container is kept alive by a detached git fsmonitor--daemon process that a Claude Code session (Desktop Code tab) spawned indirectly. Git's file-system monitor daemon (core.fsmonitor=true) is started with --detach, inherits the container job, has no package identity, and is not terminated by the updater's ForceApplicationShutdown. While that container persists, Windows refuses to create a container for the new package version ("error encountered converting the job").
Proof (occurrence 2 of 3)
Pairing AppModel-Runtime event 210 (container created) with 217 (container destroyed) per container GUID showed the container for the PREVIOUS version, Claude_1.44121.1.0_x64__pzs8sxrjxfjjc{36DD7527-…}, created 2026-09-02 14:54:37 at normal app launch, was never destroyed. Its only surviving member:
PID 32504 git.exe "git fsmonitor--daemon run --detach --ipc-threads=8"
created 2026-09-02 15:14:09, parent PID dead, IsProcessInJob = true, no package identity
named pipe \\.\pipe\C_\<repo path>\.git\fsmonitor--daemon.ipc
Terminating PID 32504 produced event 217 for {36DD7527-…} the same second, and the next launch of 1.44121.2.0 succeeded (event 201, process created). No reboot, no elevation.
Occurrence 3, same day: update 1.44121.2.0 → 1.44121.4.0 staged 09:17, registered 09:50, relaunch failed identically. Surviving member of the 1.44121.2.0 container was PID 35836, git fsmonitor--daemon for a different repository, created 09:21 by a Claude Code session inside the desktop app. Killing it destroyed the container and 1.44121.4.0 launched.
Stopping the packaged CoworkVMService made no difference (tested), so the service is not the cause here. The service-log warning failed to configure recovery actions ... open service: Access is denied (#89711 / #91195) is present but unrelated to this failure.
Ruled out
No process holds the package identity (tasklist /apps), no file handle held on the package folder
Package folder intact, manifest and signature valid, Get-AppxPackage Status = Ok
CodeIntegrity 3010 catalog warnings occur for every version including working ones (benign)
No Defender / AppLocker / Code Integrity blocks
What Should Happen?
The new version should launch after an auto-update without a reboot. Concretely:
Child processes spawned by Claude Code (Code tab / Cowork / MCP servers / terminals) inside the packaged app should not inherit the Desktop AppX container job. Break them out (CREATE_BREAKAWAY_FROM_JOB, or launch via an intermediate process outside the container) so detached daemons cannot keep the old container alive. git fsmonitor--daemon is the case found here; any --detach/daemonising child (file watchers, language servers, background node processes) will behave the same way.
Before the updater's forced shutdown/registration, enumerate the app's own container job and terminate survivors, or at least fail loudly naming them.
On relaunch failure with 0x80070020, stop looping on RepairAppRegistration (it cannot help, the package is fine) and surface the real error instead of the generic "Another program is currently using this file".
Error Messages/Logs
Microsoft-Windows-AppModel-Runtime/Admin (relaunch after update):
Event 210 Created Desktop AppX container {...} for package Claude_1.44121.2.0_x64__pzs8sxrjxfjjc
Event 211 Added process 39100 to Desktop AppX container ... (PID 39100 = cowork-svc.exe, restarted by the registration)
Event 215 0x80070020: Cannot create the Desktop AppX container for package Claude_1.44121.2.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
Event 208 0x80070020: Cannot create the process for package Claude_1.44121.2.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]
Microsoft-Windows-AppXDeploymentServer/Operational (every manual launch from Start):
Event 603 Started deployment RegisterByPackageFullName ... Options ForceTargetApplicationShutdownOption,RepairAppRegistrationOption
Event 649 Trying to repair ACLs for\\?\C:\Program Files\WindowsApps\Claude_1.44121.2.0_x64__pzs8sxrjxfjjc
Event 9650 Successfully terminated service ... CoworkVMService
Event 400 Register ... finished successfully
Update sequence (Microsoft-Windows-AppXDeploymentServer/Operational, local time):
2026-09-02 23:54 Add of Claude_1.44121.2.0 (DeferRegistrationWhenPackagesAreInUse) succeeded
2026-09-03 00:04 Register of 1.44121.2.0 failed 0x80073D02 ("apps need to be closed: Claude_1.44121.1.0")
2026-09-03 00:05 RegisterByPackageFamilyName with ForceApplicationShutdown succeeded (3 s)
2026-09-03 00:05 Relaunch failed: AppModel-Runtime 215 / 208 as above
2026-09-03 08:22-08:25 Four manual launches, each RegisterByPackageFullName + RepairAppRegistration "success", launch fails identically
2026-09-03 09:16 Killed PID 32504 (git fsmonitor--daemon) -> AppModel-Runtime 217 container {36DD7527-...} destroyed same second -> next launch event 201 Created process, app runs
Surviving process:
PID 32504 git.exe "git fsmonitor--daemon run --detach --ipc-threads=8"
created 2026-09-02 15:14:09, parent PID dead, IsProcessInJob = true, no package identity
named pipe \\.\pipe\C_\<repo path>\.git\fsmonitor--daemon.ipc
C:\ProgramData\Claude\Logs\cowork-service.log (every service start, unrelated to this failure):
Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
Steps to Reproduce
Windows 11, Claude Desktop installed as MSIX (self-updating), standard non-admin user.
Have a git repository with the file-system monitor enabled: git config core.fsmonitor true (Git for Windows 2.55.0 here).
Open the Desktop app's Code tab in that repository and let Claude Code run any git command (e.g. git status). Git spawns git fsmonitor--daemon run --detach --ipc-threads=8. Confirm it is inside the app's container job: the process has a dead parent, IsProcessInJob = true, and no package identity (tasklist /apps does not list it).
Wait for (or trigger) a Claude Desktop auto-update. The updater stages the new package, force-shuts the app (ForceApplicationShutdown), registers the new version successfully, then relaunches.
Relaunch fails with "Another program is currently using this file". Event Viewer > Microsoft-Windows-AppModel-Runtime/Admin shows events 215 and 208 with 0x80070020 "error encountered converting the job". Every manual launch from Start repeats a RegisterByPackageFullName + RepairAppRegistration that reports success and then fails identically.
Pair AppModel-Runtime events 210 and 217 by container GUID: the previous version's container has a 210 but no 217. The git fsmonitor--daemon process from step 3 is still running and is the only member of that job.
End that git.exe process (Task Manager, or Get-CimInstance Win32_Process -Filter "Name='git.exe'" | Where-Object CommandLine -like '*fsmonitor--daemon*' | ForEach-Object { Stop-Process -Id $_.ProcessId }). Event 217 fires for the old container immediately.
Launch Claude Desktop: event 201 (process created), the new version runs. No reboot, no elevation.
Reproduced three times in 24 hours (1.40609.1 → 1.44121.1 on 2026-09-02; 1.44121.1 → 1.44121.2 and 1.44121.2 → 1.44121.4 on 2026-09-03). The first two times were 'resolved' by a full reboot before the cause was known; the last two were resolved by killing the daemon.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
1.40609.1.0 (relaunch after the 2026-09-01 update worked; likely because no fsmonitor daemon had been spawned during that session, not because of a code difference)
Claude Code Version
2.1.259 (Claude Code) — bundled with Claude Desktop 1.44121.4.0 (Windows MSIX, package family Claude_pzs8sxrjxfjjc). Affected desktop versions: 1.44121.1.0, 1.44121.2.0, 1.44121.4.0
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Environment
Windows 11 Enterprise 24H2, build 26100.9168, domain-joined, standard (non-admin) user
Claude Desktop MSIX, SignatureKind = Developer, self-updating; packaged service CoworkVMService (cowork-svc.exe, LocalSystem) present
Git for Windows 2.55.0.windows.3, core.fsmonitor=true set per-repository
Microsoft Defender for Endpoint, no detections or blocks logged
How affected users can detect and fix it without a reboot
Pair events 210/217 in Microsoft-Windows-AppModel-Runtime/Admin to find a container GUID with no 217, then look for processes with a dead parent that are in a job but have no package identity. In all cases here it was exactly one git.exe with the fsmonitor--daemon command line. Ending that process (it is the user's own, no admin needed) fixes the launch immediately. Alternatively set core.fsmonitor=false in repositories opened from the desktop app.
The key fix is the one not yet proposed in any of those: spawn Claude Code's child processes with CREATE_BREAKAWAY_FROM_JOB (or via a launcher outside the container) so nothing a session starts can outlive the container. Reaping survivors at update time (#73107's suggestion) is a good second line of defence.
Happy to supply the full exported event logs (evtx) or run diagnostics on request.
Preflight Checklist
What's Wrong?
After the Claude Desktop auto-updater stages a new MSIX version and force-relaunches the app, every subsequent launch fails with the dialog "Another program is currently using this file" (HRESULT 0x80070020, AppModel-Runtime events 215/208). This symptom is already reported in #53247, #73107, #87879, #89680, #89687, #89912, #90269, #91482, #91736 and #91749, with the cause variously attributed to a race, cowork-svc.exe, an orphaned silo, or an unidentified leaked job object.
#73107 identified the correct mechanism (an orphaned Claude Code child process pinning the old version's container) with an elevated culprit (
llama-svc.exe -elevated). This report shows the same mechanism with a far more common, entirely non-elevated culprit that will hit any Windows developer using git, and gives a no-reboot, no-elevation workaround. Reproduced three times in 24 hours across three consecutive updates (1.40609.1 → 1.44121.1 → 1.44121.2 → 1.44121.4).The old version's Desktop AppX container is kept alive by a detached
git fsmonitor--daemonprocess that a Claude Code session (Desktop Code tab) spawned indirectly. Git's file-system monitor daemon (core.fsmonitor=true) is started with--detach, inherits the container job, has no package identity, and is not terminated by the updater'sForceApplicationShutdown. While that container persists, Windows refuses to create a container for the new package version ("error encountered converting the job").Proof (occurrence 2 of 3)
Pairing AppModel-Runtime event 210 (container created) with 217 (container destroyed) per container GUID showed the container for the PREVIOUS version,
Claude_1.44121.1.0_x64__pzs8sxrjxfjjc{36DD7527-…}, created 2026-09-02 14:54:37 at normal app launch, was never destroyed. Its only surviving member:Terminating PID 32504 produced event 217 for
{36DD7527-…}the same second, and the next launch of 1.44121.2.0 succeeded (event 201, process created). No reboot, no elevation.Occurrence 3, same day: update 1.44121.2.0 → 1.44121.4.0 staged 09:17, registered 09:50, relaunch failed identically. Surviving member of the 1.44121.2.0 container was PID 35836,
git fsmonitor--daemonfor a different repository, created 09:21 by a Claude Code session inside the desktop app. Killing it destroyed the container and 1.44121.4.0 launched.Stopping the packaged CoworkVMService made no difference (tested), so the service is not the cause here. The service-log warning
failed to configure recovery actions ... open service: Access is denied(#89711 / #91195) is present but unrelated to this failure.Ruled out
tasklist /apps), no file handle held on the package folderGet-AppxPackageStatus = OkWhat Should Happen?
The new version should launch after an auto-update without a reboot. Concretely:
CREATE_BREAKAWAY_FROM_JOB, or launch via an intermediate process outside the container) so detached daemons cannot keep the old container alive.git fsmonitor--daemonis the case found here; any--detach/daemonising child (file watchers, language servers, background node processes) will behave the same way.RepairAppRegistration(it cannot help, the package is fine) and surface the real error instead of the generic "Another program is currently using this file".Error Messages/Logs
Microsoft-Windows-AppModel-Runtime/Admin (relaunch after update): Event 210 Created Desktop AppX container {...} for package Claude_1.44121.2.0_x64__pzs8sxrjxfjjc Event 211 Added process 39100 to Desktop AppX container ... (PID 39100 = cowork-svc.exe, restarted by the registration) Event 215 0x80070020: Cannot create the Desktop AppX container for package Claude_1.44121.2.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job. Event 208 0x80070020: Cannot create the process for package Claude_1.44121.2.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess] Microsoft-Windows-AppXDeploymentServer/Operational (every manual launch from Start): Event 603 Started deployment RegisterByPackageFullName ... Options ForceTargetApplicationShutdownOption,RepairAppRegistrationOption Event 649 Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_1.44121.2.0_x64__pzs8sxrjxfjjc Event 9650 Successfully terminated service ... CoworkVMService Event 400 Register ... finished successfully Update sequence (Microsoft-Windows-AppXDeploymentServer/Operational, local time): 2026-09-02 23:54 Add of Claude_1.44121.2.0 (DeferRegistrationWhenPackagesAreInUse) succeeded 2026-09-03 00:04 Register of 1.44121.2.0 failed 0x80073D02 ("apps need to be closed: Claude_1.44121.1.0") 2026-09-03 00:05 RegisterByPackageFamilyName with ForceApplicationShutdown succeeded (3 s) 2026-09-03 00:05 Relaunch failed: AppModel-Runtime 215 / 208 as above 2026-09-03 08:22-08:25 Four manual launches, each RegisterByPackageFullName + RepairAppRegistration "success", launch fails identically 2026-09-03 09:16 Killed PID 32504 (git fsmonitor--daemon) -> AppModel-Runtime 217 container {36DD7527-...} destroyed same second -> next launch event 201 Created process, app runs Surviving process: PID 32504 git.exe "git fsmonitor--daemon run --detach --ipc-threads=8" created 2026-09-02 15:14:09, parent PID dead, IsProcessInJob = true, no package identity named pipe \\.\pipe\C_\<repo path>\.git\fsmonitor--daemon.ipc C:\ProgramData\Claude\Logs\cowork-service.log (every service start, unrelated to this failure): Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.Steps to Reproduce
git config core.fsmonitor true(Git for Windows 2.55.0 here).gitcommand (e.g.git status). Git spawnsgit fsmonitor--daemon run --detach --ipc-threads=8. Confirm it is inside the app's container job: the process has a dead parent,IsProcessInJob= true, and no package identity (tasklist /appsdoes not list it).ForceApplicationShutdown), registers the new version successfully, then relaunches.git fsmonitor--daemonprocess from step 3 is still running and is the only member of that job.Get-CimInstance Win32_Process -Filter "Name='git.exe'" | Where-Object CommandLine -like '*fsmonitor--daemon*' | ForEach-Object { Stop-Process -Id $_.ProcessId }). Event 217 fires for the old container immediately.Reproduced three times in 24 hours (1.40609.1 → 1.44121.1 on 2026-09-02; 1.44121.1 → 1.44121.2 and 1.44121.2 → 1.44121.4 on 2026-09-03). The first two times were 'resolved' by a full reboot before the cause was known; the last two were resolved by killing the daemon.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
1.40609.1.0 (relaunch after the 2026-09-01 update worked; likely because no fsmonitor daemon had been spawned during that session, not because of a code difference)
Claude Code Version
2.1.259 (Claude Code) — bundled with Claude Desktop 1.44121.4.0 (Windows MSIX, package family Claude_pzs8sxrjxfjjc). Affected desktop versions: 1.44121.1.0, 1.44121.2.0, 1.44121.4.0
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Environment
core.fsmonitor=trueset per-repositoryHow affected users can detect and fix it without a reboot
Pair events 210/217 in
Microsoft-Windows-AppModel-Runtime/Adminto find a container GUID with no 217, then look for processes with a dead parent that are in a job but have no package identity. In all cases here it was exactly onegit.exewith thefsmonitor--daemoncommand line. Ending that process (it is the user's own, no admin needed) fixes the launch immediately. Alternatively setcore.fsmonitor=falsein repositories opened from the desktop app.Relationship to existing issues
has repro): same mechanism, an orphaned Claude Code child pinning the old container, but the culprit there was an elevatedllama-svc.execonsole. Here it is an unelevatedgit fsmonitor--daemon, which any Windows git user withcore.fsmonitorenabled will spawn on the firstgit status. That makes the failure far more widespread than [BUG] Windows desktop app won't launch after package upgrade: "Another program is currently using this file" (0x80070020) -- old version's AppX container silo pinned by an orphaned elevated Claude Code child process #73107 alone suggests, and explains why it recurs on every update for some users.invalid/duplicate, and [BUG] MSIX in-place update leaks a container silo, making Claude Desktop unlaunchable until reboot (0x80070020) #87879 ruled out surviving container members entirely, which suggests the root cause has been missed during triage.The key fix is the one not yet proposed in any of those: spawn Claude Code's child processes with
CREATE_BREAKAWAY_FROM_JOB(or via a launcher outside the container) so nothing a session starts can outlive the container. Reaping survivors at update time (#73107's suggestion) is a good second line of defence.Happy to supply the full exported event logs (evtx) or run diagnostics on request.