[BUG] Windows: Crash exit leaves stale AppContainer job (<code>Container_Claude_...</code>) held by <code>svchost.exe</code>, blocking relaunch with "Another program is currently using this file" — only reboot clears it
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
<html>
<body>
<!--StartFragment--><html><head></head><body><hr>
<h1>Windows: Crash exit leaves stale AppContainer job (<code>Container_Claude_...</code>) held by <code>svchost.exe</code>, blocking relaunch with "Another program is currently using this file" — only reboot clears it</h1>
<p><strong>Version:</strong> Claude_1.20186.7.0 (Windows)</p>
<h2>What's wrong</h2>
<p>After Claude Desktop terminates unexpectedly (crash, not a normal close), attempting to reopen the app fails:</p>
<ol>
<li>
<p><code>cowork-svc.exe</code> spawns in Task Manager (~13.6 MB), then a popup appears: <code>Another program is currently using this file</code>, referencing <code>C:\Program Files\WindowsApps\Claude_1.20186.7.0_...</code> — main window never opens.</p>
<p><em>(attach screenshot here — the dialog you shared earlier)</em></p>
</li>
<li>
<p>On at least one occasion, a "Please wait a moment, we are updating the app" message appeared instead, then nothing further happened (no completion, no error, no retry).</p>
</li>
</ol>
<h2>Root cause (identified via Resource Monitor / Process Explorer)</h2>
<p>No visible Claude process holds the lock. Instead, <code>svchost.exe</code> (running <code>netsvcs -p</code>) holds a Job handle to <code>\Container_Claude_1.20186.0.0_x...</code> — the AppContainer job object for the packaged app. This job object survives the crash and is never released, blocking the next launch attempt from acquiring the package's file lock.</p>
<p>A related lead: <code>services.exe</code> holds multiple Semaphore handles named <code>DaxUseSemaphore_Claude_1.20186...</code> (tied to the Desktop Bridge / Desktop App Converter runtime used to run the packaged Win32 app). These may be contributing to, or be a symptom of, the same underlying teardown failure.</p>
<h2>Tested (all failed to resolve without reboot)</h2>
<ul>
<li>Manually killing <code>cowork-svc.exe</code> in Task Manager — no effect</li>
<li>Restarting the AppX Deployment service (<code>Restart-Service -Name AppXSvc -Force</code>) — no effect</li>
<li>Confirmed via <code>Get-AppxPackage -Name "Claude" | Select Name, PackageFullName, Status</code> that the package registration itself is healthy (<code>Status: Ok</code>) — not a corrupted registration issue</li>
<li>Killing the specific <code>svchost.exe</code> PID holding the <code>Container_Claude_...</code> job handle (via Resource Monitor) — Windows immediately respawned a new <code>svchost.exe</code> under a new PID to take over the same service group; the block persisted</li>
<li>Full system reboot → only fix that works</li>
</ul>
<h2>Confirmed underlying cause (Event Viewer + folder check)</h2>
<p>Windows Event Viewer shows Event ID 2562 from <code>Microsoft-Windows-AppXDeploymentServer/Operational</code>, logged around the time of a failed relaunch attempt:</p>
<pre><code>MSIXDeployment / windows.applicationData / DeleteMachineFolder
Package Claude_1.20186.0.0_x64__pzs8sxrjxfjjc removed machine folder
C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc:
The system cannot find the path specified.
</code></pre>
<p>Manually verified afterward:</p>
<pre><code class="language-powershell">Test-Path "C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc"
Returns: False
</code></pre>
<p>This folder is missing even outside the crash window (confirmed while the app was otherwise stuck/unable to launch), not just transiently during the failed relaunch. This means:</p>
<ul>
<li>On relaunch after a crash, Windows' AppX deployment service attempts an MSIX servicing operation that includes a <code>DeleteMachineFolder</code> step against this path.</li>
<li>That step fails immediately because the folder doesn't exist.</li>
<li>The deployment operation appears to error out mid-flight without rolling back cleanly, leaving the AppContainer job object (<code>Container_Claude_...</code>, see below) stuck in a "still in use" state under <code>svchost.exe</code>'s job tracking.</li>
<li>Because the underlying missing-folder condition is persistent (not cleared by reboot), this will recur on every subsequent crash until the app's data folder is properly repaired/recreated.</li>
</ul>
<h2>Timeline reconstructed from <code>C:\ProgramData\Claude\Logs\cowork-service.log</code></h2>
<p>The service log (not reviewed at the time of the original write-up) corroborates the crash/stuck-relaunch pattern with a precise, quantified timeline for one occurrence on 2026-07-13:</p>
Time | Preceded by clean stop? | Notes
-- | -- | --
(before 21:16) | — | Original unexpected app closure. Not visible in this log — cowork-svc.exe crashing doesn't log its own death.
21:16:01 | ✅ (stop at 21:16:00) | User manually stopped the service as a troubleshooting step, then restarted it — relaunch still fails.
21:16:34 | ❌ | First occurrence of the no-clean-stop signature.
21:19:11 | ❌ |
21:19:16 | ✅ (stop at 21:19:12) |
21:22:52 | ❌ |
21:25:09 | ✅ (stop at 21:25:09) |
21:25:40 | ❌ |
21:26:54 | ✅ (stop at 21:26:53) |
21:32:05 | ❌ |
21:47:32 | ❌ |
21:47:33 – 22:21:24 | — | 34-minute gap, nothing logged — likely the window spent on the workarounds listed above, before proceeding to a full reboot.
22:21:24 | ❌ (different cause — see below) | This attempt succeeded — app launched normally, matching "only reboot fixed it." No-stop here reflects the OS killing everything at reboot, not a repeat of the stuck-lock failure.
<p><strong>Net result:</strong> 7 of the 11 restarts during troubleshooting (21:16:34, 21:19:11, 21:22:52, 21:25:40, 21:32:05, 21:47:32, 22:21:24) show no clean stop logged beforehand. Of those, 6 (all but the final, post-reboot one) share the same mechanism: the previous attempt's <code>cowork-svc.exe</code> never registered a proper shutdown before the next attempt started. The 4 "clean stop" restarts (21:16:01, 21:19:16, 21:25:09, 21:26:54) are the moments something in between — a manual kill, or a Windows timeout — let it register a stop before the next attempt.</p>
<p>This is the more precise failure mode: it isn't just "the app crashed once, then relaunch fails" — it's "when the launch hits the file lock, the service itself doesn't shut down cleanly, so each retry piles a new attempt on top of a service that never cleanly exited from the last one." That's consistent with the AppContainer job staying alive in the background even though nothing appears to be running, and it's a stronger signal than a simple one-time crash: the failure to open <em>is itself</em> what prevents a clean stop, which is exactly what you'd expect if the stuck job/file-lock is blocking the shutdown path too, not just the startup path.</p>
<p>One log line present on every single start (both clean and crashed) is worth flagging separately in case it's relevant: <code>Warning: failed to open service for recovery config: Access is denied.</code> This appears consistently regardless of shutdown type and may be an unrelated SCM permission quirk — but it's worth Anthropic ruling out explicitly rather than assuming it's benign.</p>
<h2>Post-reboot contrast</h2>
<p>After rebooting, the app launched successfully. The <code>CoworkVMService</code> event logged on this successful start was simply "Claude VM Service starting" with a reference to detailed logs at <code>C:\ProgramData\Claude\Logs\cowork-service.log</code> — no folder-not-found or deployment error accompanied it. This is a clean contrast to the failed relaunch attempts, which specifically triggered the <code>DeleteMachineFolder</code> path-not-found error.</p>
<p>This strongly suggests a repair or reinstall (not just a reboot) is needed to permanently resolve this, since reboot only clears the immediate stuck job/lock state — it does not recreate the missing <code>ApplicationData</code> folder, so the same failure will repeat after the next crash.</p>
<h2>Why this matters</h2>
<p>Even directly targeting and killing the process holding the job handle doesn't release it — Windows simply reassigns the service group to a fresh <code>svchost.exe</code> instance rather than releasing the stale job object. This indicates the AppContainer job's state is tracked at a level that isn't cleared by process-level intervention, only by a full session/kernel reset (reboot).</p>
<p>The <code>cowork-service.log</code> timeline above sharpens this conclusion: the failure mode isn't just "the app crashed once, and relaunch happens to fail afterward." It's that <strong>the failed-launch path itself doesn't shut the service down cleanly</strong> — 6 of 7 no-clean-stop restarts occur specifically when retrying on top of the stuck file lock, not as isolated one-off crashes. That means the same stuck-lock condition that blocks startup is also preventing a clean stop, which is consistent with the AppContainer job never being released: the job stays alive in the background even though nothing user-visible appears to be running, so neither the next launch attempt nor the current instance's own shutdown can complete cleanly.</p>
<p>Sign-out was not tested as a lighter-weight alternative to reboot, since it also risks unsaved app state — but if it were confirmed to work, that would narrow the stale state to session-level rather than full boot-level. Untested here, but worth Anthropic checking as a possible faster user-facing recovery path if the underlying job can't be fixed to release cleanly on crash.</p>
<h2>Ask</h2>
<ul>
<li>The app (or its installer/updater) should ensure <code>C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc</code> exists and is valid, and should tolerate/recreate it if missing, rather than letting the <code>DeleteMachineFolder</code> MSIX servicing step fail outright when the path is absent.</li>
<li>The AppX deployment operation triggered on relaunch should roll back cleanly if a step like <code>DeleteMachineFolder</code> fails, instead of leaving the AppContainer job object (<code>Container_Claude_...</code>) in a stuck "in use" state.</li>
<li>Would help to know if the failed-launch path skips releasing the AppContainer job object when it hits the stuck file lock, and whether that can be fixed so a clean job teardown happens even when launch fails (not just on a graceful exit). The service log shows 6 of 7 no-clean-stop restarts occurring specifically on retries against the stuck lock — i.e. the failure to open is itself preventing a clean shutdown, not just blocking startup. Worth checking whether <code>cowork-svc.exe</code> can be made to log (or attempt) cleanup even when a launch attempt fails partway through.</li>
<li>Is there a way to force-release the job/lock via a repair/reset routine (similar to <code>wsreset</code> for other AppX apps) without requiring a full OS reboot, once the missing-folder condition is fixed?</li>
<li>Worth investigating whether the <code>DaxUseSemaphore_Claude_...</code> semaphores held by <code>services.exe</code> are related or a separate leak.</li>
<li>Worth ruling out whether <code>Warning: failed to open service for recovery config: Access is denied.</code> (logged on every single service start, clean or crashed) is related or a separate, benign permission issue.</li>
</ul>
<h2>Suggested workaround for other affected users</h2>
<p>After the next unavoidable reboot, run a Repair (not just relaunch) via Settings → Apps → Installed apps → Claude → Advanced options → Repair, to attempt to recreate the missing <code>ApplicationData</code> folder. If Repair doesn't recreate it, a full uninstall/reinstall may be required — a plain reboot only clears the immediate stuck lock, it does not fix the underlying missing folder, so the same crash-triggered lock is expected to recur.</p>
<h2>Environment</h2>
<ul>
<li>OS: Windows 11 Home, build 10.0.26200</li>
<li>Claude Desktop version: 1.20186.7.0 (confirmed current via <code>Get-AppxPackage -Name "Claude"</code>)</li>
<li>Trigger: unexpected/crash shutdown of the app (not a normal close)</li>
<li>Confirmed via: Task Manager, Resource Monitor (Associated Handles), Process Explorer (Sysinternals), <code>C:\ProgramData\Claude\Logs\cowork-service.log</code></li>
</ul></body></html><!--EndFragment-->
</body>
</html>
What Should Happen?
open the app
Error Messages/Logs
app cannot be openSteps to Reproduce
<html>
<body>
<!--StartFragment--><html><head></head><body><hr>
<h1>Windows: Crash exit leaves stale AppContainer job (<code>Container_Claude_...</code>) held by <code>svchost.exe</code>, blocking relaunch with "Another program is currently using this file" — only reboot clears it</h1>
<p><strong>Version:</strong> Claude_1.20186.7.0 (Windows)</p>
<h2>What's wrong</h2>
<p>After Claude Desktop terminates unexpectedly (crash, not a normal close), attempting to reopen the app fails:</p>
<ol>
<li>
<p><code>cowork-svc.exe</code> spawns in Task Manager (~13.6 MB), then a popup appears: <code>Another program is currently using this file</code>, referencing <code>C:\Program Files\WindowsApps\Claude_1.20186.7.0_...</code> — main window never opens.</p>
<p><em>(attach screenshot here — the dialog you shared earlier)</em></p>
</li>
<li>
<p>On at least one occasion, a "Please wait a moment, we are updating the app" message appeared instead, then nothing further happened (no completion, no error, no retry).</p>
</li>
</ol>
<h2>Root cause (identified via Resource Monitor / Process Explorer)</h2>
<p>No visible Claude process holds the lock. Instead, <code>svchost.exe</code> (running <code>netsvcs -p</code>) holds a Job handle to <code>\Container_Claude_1.20186.0.0_x...</code> — the AppContainer job object for the packaged app. This job object survives the crash and is never released, blocking the next launch attempt from acquiring the package's file lock.</p>
<p>A related lead: <code>services.exe</code> holds multiple Semaphore handles named <code>DaxUseSemaphore_Claude_1.20186...</code> (tied to the Desktop Bridge / Desktop App Converter runtime used to run the packaged Win32 app). These may be contributing to, or be a symptom of, the same underlying teardown failure.</p>
<h2>Tested (all failed to resolve without reboot)</h2>
<ul>
<li>Manually killing <code>cowork-svc.exe</code> in Task Manager — no effect</li>
<li>Restarting the AppX Deployment service (<code>Restart-Service -Name AppXSvc -Force</code>) — no effect</li>
<li>Confirmed via <code>Get-AppxPackage -Name "Claude" | Select Name, PackageFullName, Status</code> that the package registration itself is healthy (<code>Status: Ok</code>) — not a corrupted registration issue</li>
<li>Killing the specific <code>svchost.exe</code> PID holding the <code>Container_Claude_...</code> job handle (via Resource Monitor) — Windows immediately respawned a new <code>svchost.exe</code> under a new PID to take over the same service group; the block persisted</li>
<li>Full system reboot → only fix that works</li>
</ul>
<h2>Confirmed underlying cause (Event Viewer + folder check)</h2>
<p>Windows Event Viewer shows Event ID 2562 from <code>Microsoft-Windows-AppXDeploymentServer/Operational</code>, logged around the time of a failed relaunch attempt:</p>
<pre><code>MSIXDeployment / windows.applicationData / DeleteMachineFolder
Package Claude_1.20186.0.0_x64__pzs8sxrjxfjjc removed machine folder
C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc:
The system cannot find the path specified.
</code></pre>
<p>Manually verified afterward:</p>
<pre><code class="language-powershell">Test-Path "C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc"
Returns: False
</code></pre>
<p>This folder is missing even outside the crash window (confirmed while the app was otherwise stuck/unable to launch), not just transiently during the failed relaunch. This means:</p>
<ul>
<li>On relaunch after a crash, Windows' AppX deployment service attempts an MSIX servicing operation that includes a <code>DeleteMachineFolder</code> step against this path.</li>
<li>That step fails immediately because the folder doesn't exist.</li>
<li>The deployment operation appears to error out mid-flight without rolling back cleanly, leaving the AppContainer job object (<code>Container_Claude_...</code>, see below) stuck in a "still in use" state under <code>svchost.exe</code>'s job tracking.</li>
<li>Because the underlying missing-folder condition is persistent (not cleared by reboot), this will recur on every subsequent crash until the app's data folder is properly repaired/recreated.</li>
</ul>
<h2>Timeline reconstructed from <code>C:\ProgramData\Claude\Logs\cowork-service.log</code></h2>
<p>The service log (not reviewed at the time of the original write-up) corroborates the crash/stuck-relaunch pattern with a precise, quantified timeline for one occurrence on 2026-07-13:</p>
Time | Preceded by clean stop? | Notes
-- | -- | --
(before 21:16) | — | Original unexpected app closure. Not visible in this log — cowork-svc.exe crashing doesn't log its own death.
21:16:01 | ✅ (stop at 21:16:00) | User manually stopped the service as a troubleshooting step, then restarted it — relaunch still fails.
21:16:34 | ❌ | First occurrence of the no-clean-stop signature.
21:19:11 | ❌ |
21:19:16 | ✅ (stop at 21:19:12) |
21:22:52 | ❌ |
21:25:09 | ✅ (stop at 21:25:09) |
21:25:40 | ❌ |
21:26:54 | ✅ (stop at 21:26:53) |
21:32:05 | ❌ |
21:47:32 | ❌ |
21:47:33 – 22:21:24 | — | 34-minute gap, nothing logged — likely the window spent on the workarounds listed above, before proceeding to a full reboot.
22:21:24 | ❌ (different cause — see below) | This attempt succeeded — app launched normally, matching "only reboot fixed it." No-stop here reflects the OS killing everything at reboot, not a repeat of the stuck-lock failure.
<p><strong>Net result:</strong> 7 of the 11 restarts during troubleshooting (21:16:34, 21:19:11, 21:22:52, 21:25:40, 21:32:05, 21:47:32, 22:21:24) show no clean stop logged beforehand. Of those, 6 (all but the final, post-reboot one) share the same mechanism: the previous attempt's <code>cowork-svc.exe</code> never registered a proper shutdown before the next attempt started. The 4 "clean stop" restarts (21:16:01, 21:19:16, 21:25:09, 21:26:54) are the moments something in between — a manual kill, or a Windows timeout — let it register a stop before the next attempt.</p>
<p>This is the more precise failure mode: it isn't just "the app crashed once, then relaunch fails" — it's "when the launch hits the file lock, the service itself doesn't shut down cleanly, so each retry piles a new attempt on top of a service that never cleanly exited from the last one." That's consistent with the AppContainer job staying alive in the background even though nothing appears to be running, and it's a stronger signal than a simple one-time crash: the failure to open <em>is itself</em> what prevents a clean stop, which is exactly what you'd expect if the stuck job/file-lock is blocking the shutdown path too, not just the startup path.</p>
<p>One log line present on every single start (both clean and crashed) is worth flagging separately in case it's relevant: <code>Warning: failed to open service for recovery config: Access is denied.</code> This appears consistently regardless of shutdown type and may be an unrelated SCM permission quirk — but it's worth Anthropic ruling out explicitly rather than assuming it's benign.</p>
<h2>Post-reboot contrast</h2>
<p>After rebooting, the app launched successfully. The <code>CoworkVMService</code> event logged on this successful start was simply "Claude VM Service starting" with a reference to detailed logs at <code>C:\ProgramData\Claude\Logs\cowork-service.log</code> — no folder-not-found or deployment error accompanied it. This is a clean contrast to the failed relaunch attempts, which specifically triggered the <code>DeleteMachineFolder</code> path-not-found error.</p>
<p>This strongly suggests a repair or reinstall (not just a reboot) is needed to permanently resolve this, since reboot only clears the immediate stuck job/lock state — it does not recreate the missing <code>ApplicationData</code> folder, so the same failure will repeat after the next crash.</p>
<h2>Why this matters</h2>
<p>Even directly targeting and killing the process holding the job handle doesn't release it — Windows simply reassigns the service group to a fresh <code>svchost.exe</code> instance rather than releasing the stale job object. This indicates the AppContainer job's state is tracked at a level that isn't cleared by process-level intervention, only by a full session/kernel reset (reboot).</p>
<p>The <code>cowork-service.log</code> timeline above sharpens this conclusion: the failure mode isn't just "the app crashed once, and relaunch happens to fail afterward." It's that <strong>the failed-launch path itself doesn't shut the service down cleanly</strong> — 6 of 7 no-clean-stop restarts occur specifically when retrying on top of the stuck file lock, not as isolated one-off crashes. That means the same stuck-lock condition that blocks startup is also preventing a clean stop, which is consistent with the AppContainer job never being released: the job stays alive in the background even though nothing user-visible appears to be running, so neither the next launch attempt nor the current instance's own shutdown can complete cleanly.</p>
<p>Sign-out was not tested as a lighter-weight alternative to reboot, since it also risks unsaved app state — but if it were confirmed to work, that would narrow the stale state to session-level rather than full boot-level. Untested here, but worth Anthropic checking as a possible faster user-facing recovery path if the underlying job can't be fixed to release cleanly on crash.</p>
<h2>Ask</h2>
<ul>
<li>The app (or its installer/updater) should ensure <code>C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc</code> exists and is valid, and should tolerate/recreate it if missing, rather than letting the <code>DeleteMachineFolder</code> MSIX servicing step fail outright when the path is absent.</li>
<li>The AppX deployment operation triggered on relaunch should roll back cleanly if a step like <code>DeleteMachineFolder</code> fails, instead of leaving the AppContainer job object (<code>Container_Claude_...</code>) in a stuck "in use" state.</li>
<li>Would help to know if the failed-launch path skips releasing the AppContainer job object when it hits the stuck file lock, and whether that can be fixed so a clean job teardown happens even when launch fails (not just on a graceful exit). The service log shows 6 of 7 no-clean-stop restarts occurring specifically on retries against the stuck lock — i.e. the failure to open is itself preventing a clean shutdown, not just blocking startup. Worth checking whether <code>cowork-svc.exe</code> can be made to log (or attempt) cleanup even when a launch attempt fails partway through.</li>
<li>Is there a way to force-release the job/lock via a repair/reset routine (similar to <code>wsreset</code> for other AppX apps) without requiring a full OS reboot, once the missing-folder condition is fixed?</li>
<li>Worth investigating whether the <code>DaxUseSemaphore_Claude_...</code> semaphores held by <code>services.exe</code> are related or a separate leak.</li>
<li>Worth ruling out whether <code>Warning: failed to open service for recovery config: Access is denied.</code> (logged on every single service start, clean or crashed) is related or a separate, benign permission issue.</li>
</ul>
<h2>Suggested workaround for other affected users</h2>
<p>After the next unavoidable reboot, run a Repair (not just relaunch) via Settings → Apps → Installed apps → Claude → Advanced options → Repair, to attempt to recreate the missing <code>ApplicationData</code> folder. If Repair doesn't recreate it, a full uninstall/reinstall may be required — a plain reboot only clears the immediate stuck lock, it does not fix the underlying missing folder, so the same crash-triggered lock is expected to recur.</p>
<h2>Environment</h2>
<ul>
<li>OS: Windows 11 Home, build 10.0.26200</li>
<li>Claude Desktop version: 1.20186.7.0 (confirmed current via <code>Get-AppxPackage -Name "Claude"</code>)</li>
<li>Trigger: unexpected/crash shutdown of the app (not a normal close)</li>
<li>Confirmed via: Task Manager, Resource Monitor (Associated Handles), Process Explorer (Sysinternals), <code>C:\ProgramData\Claude\Logs\cowork-service.log</code></li>
</ul></body></html><!--EndFragment-->
</body>
</html>
Claude Model
Other
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
not 1.20
Platform
Other
Operating System
Windows
Terminal/Shell
Other
Additional Information
<img width="397" height="155" alt="Image" src="https://github.com/user-attachments/assets/f80a5290-9588-4649-8860-799da0727779" />