Bug Report: Windows installer fails with AddPackage 0x80073CF6 / 0x80073CF9 when a leftover CoworkVMService exists, and the bootstrapper cannot remove it (Access denied) but continues anyway
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><h1>Bug Report: Windows installer fails with AddPackage 0x80073CF6 / 0x80073CF9 when a leftover <code>CoworkVMService</code> exists, and the bootstrapper cannot remove it (Access denied) but continues anyway</h1>
<h2>Summary</h2>
<p>On Windows 10 Pro 22H2, the Claude Desktop MSIX installer fails at the package
registration stage whenever a leftover <code>CoworkVMService</code> is present on the machine.</p>
<p>The bootstrapper <strong>detects</strong> the conflict, <strong>tries</strong> to remove the service while running
elevated, <strong>fails</strong> with <code>Access is denied</code>, logs it only as a <code>WARNING</code>, and then proceeds
to call <code>AddPackage</code> anyway — which fails. The user is shown a misleading dialog
("Administrator access is required...") even though the installer was already running
fully elevated.</p>
<p>The correlation in a single log file is 4-for-4 and deterministic.</p>
<h2>Environment</h2>
Field | Value
-- | --
OS | Windows 10 Professional, 10.0.19045 (22H2), x64
Bootstrapper | Claude Setup build 255293a41a25d54c5177aa9614fb4cd620e70b78
Target package | Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
MSIX SHA256 | ad5ead595fec1977c0ccb1d7fab3be040773b716451431dbd6bab457ba31a55c
Sideloading | enabled
S Mode | false
Developer mode | off
Log | C:\Users\<user>\AppData\Local\Temp\ClaudeSetup.log
<p>Every run downloaded the identical MSIX (same SHA256) and passed Authenticode
verification (<code>WinVerifyTrust: MSIX signature is valid</code>, <code>Signature verified: MSIX signer matches bootstrapper</code>). So this is not a download-integrity or signing problem — it is a
registration-stage failure gated on the leftover service.</p>
<p><code>0x80073CF6</code> = "Package could not be registered."
<code>0x80073CF9</code> = <code>ERROR_INSTALL_REGISTRATION_FAILURE</code> — "Install failed. Please contact
your software vendor."</p>
<h2>The core defect</h2>
<p>From the 08:44 run, elevated (<code>Is elevated: true</code>, <code>Elevation type: Full</code>):</p>
<pre><code>08:44:33.521786 WARNING: CoworkVMService already exists (potential conflict)
08:44:33.521786 Conflicting service: true
08:44:35.328479 Removing conflicting CoworkVMService...
08:44:35.329003 WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
08:44:35.329003 Checking for existing Claude MSIX packages...
...
08:44:35.357513 Installing via AddPackage (current-user)...
08:44:38.131311 MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
</code></pre>
<p>Three problems, in order of severity:</p>
<p><strong>1. The installer continues after a failed prerequisite.</strong> It knows the conflicting
service is still there. It knows removal failed. It proceeds to <code>AddPackage</code> regardless,
turning a known, nameable precondition failure into an opaque HRESULT.</p>
<p><strong>2. <code>OpenService</code> returns <code>Access is denied</code> in a fully-elevated context.</strong> This suggests
the service is running and/or its DACL denies <code>DELETE</code>/<code>SERVICE_STOP</code> to Administrators.
The installer does not appear to attempt <code>ControlService(SERVICE_CONTROL_STOP)</code> before
<code>DeleteService</code>, nor to enable <code>SeTakeOwnershipPrivilege</code> / adjust the SCM object's DACL.</p>
<p><strong>3. The error dialog names the wrong cause.</strong> The user sees:</p>
<pre><code>Administrator access is required to install Claude with full features.
You can try again or install without Cowork.
</code></pre>
<p>The installer <em>had</em> administrator access — the log says so on the line above. Retrying
does nothing, because the leftover service is still there. The dialog sends the user into
a loop of re-downloading a 247 MB package (four times in this log alone).</p>
<h2>Secondary defect: credentials are lost on every failed cycle</h2>
<pre><code>08:44:35.345714 Windows rejected data-preserving removal for Claude_1.34493.1.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
08:44:35.354512 Removing (user): Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
08:44:35.357513 Windows rejected data-preserving removal ... relying on in-place update
</code></pre>
<p><code>0x80073CFA</code> is <code>ERROR_REMOVE_FAILED</code>; <code>Remove-AppxPackage -PreserveApplicationData</code>
requires developer mode, which is off on this machine (and off by default for most users).
The installer falls back to "relying on in-place update" — but on the failure path the
in-place update never completes, and application data does not survive.</p>
<p><strong>User-visible consequence:</strong> the user is forced to sign in again after every failed
install attempt. This was the symptom they originally reported ("it keeps asking me to
sign in"), and they had no way to connect it to the installer. Repeated re-authentication
with no explanation reads to the user as an authentication bug.</p>
<h2>Steps to reproduce</h2>
<ol>
<li>On Windows 10 22H2 (developer mode off), install Claude Desktop with Cowork so that
<code>CoworkVMService</code> is registered.</li>
<li>Put the service into a state the installer cannot open for deletion — observed after a
prior failed/partial install, and reproduced after a reboot with the service running.</li>
<li>Run <code>Claude Setup.exe</code> and allow elevation.</li>
<li>Observe: <code>Conflicting service: true</code> → <code>failed to remove conflicting service: ... Access is denied</code>
→ <code>AddPackage failed with HRESULT 0x80073CF6</code> or <code>0x80073CF9</code> → the
"Administrator access is required" dialog.</li>
</ol>
<h2>Expected behavior</h2>
<ul>
<li>If the conflicting service cannot be removed, <strong>stop before calling <code>AddPackage</code></strong> and
show an actionable message naming <code>CoworkVMService</code>, with the remediation commands.</li>
<li>Attempt <code>ControlService(SERVICE_CONTROL_STOP)</code> and wait for <code>SERVICE_STOPPED</code> before
<code>DeleteService</code>. If the service is marked for deletion, tell the user a reboot is
required and offer to schedule it.</li>
<li>Never show "Administrator access is required" when <code>Is elevated: true</code> is in the log
three lines above. Surface the actual HRESULT and its meaning.</li>
<li>Preserve credentials across a failed install, or state plainly in the failure dialog
that the user will need to sign in again.</li>
<li>Document the Windows 10 22H2 support status for Cowork. If Cowork's virtualization
service is not supported on Windows 10, the installer should say so up front rather than
register a service it cannot later clean up.</li>
</ul>
<h2>Working user workaround</h2>
<p>Elevated PowerShell / cmd:</p>
<pre><code class="language-powershell">sc.exe query CoworkVMService
sc.exe stop CoworkVMService
sc.exe delete CoworkVMService
</code></pre>
<p>Reboot, then re-run the installer. In this log, both runs where the service was absent
(<code>Conflicting service: false</code>) installed successfully in under 20 seconds.</p>
<p>If <code>sc.exe delete</code> also returns access denied, the service DACL must be repaired
(<code>sc.exe sdset</code>) or the removal done from Safe Mode.</p>
<h2>Impact</h2>
<ul>
<li>Install fails with no actionable diagnostic; the dialog actively misdirects.</li>
<li>247 MB re-downloaded on every retry.</li>
<li>User is signed out repeatedly with no stated cause, which is the symptom they perceive
and report — not the install failure that causes it.</li>
</ul></body></html><!--EndFragment-->
</body>
</html>
What Should Happen?
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Bug Report: Windows installer fails with AddPackage 0x80073CF6 / 0x80073CF9 when a leftover <code>CoworkVMService</code> exists, and the bootstrapper cannot remove it (Access denied) but continues anyway</h1>
<h2>Summary</h2>
<p>On Windows 10 Pro 22H2, the Claude Desktop MSIX installer fails at the package
registration stage whenever a leftover <code>CoworkVMService</code> is present on the machine.</p>
<p>The bootstrapper <strong>detects</strong> the conflict, <strong>tries</strong> to remove the service while running
elevated, <strong>fails</strong> with <code>Access is denied</code>, logs it only as a <code>WARNING</code>, and then proceeds
to call <code>AddPackage</code> anyway — which fails. The user is shown a misleading dialog
("Administrator access is required...") even though the installer was already running
fully elevated.</p>
<p>The correlation in a single log file is 4-for-4 and deterministic.</p>
<h2>Environment</h2>
Field | Value
-- | --
OS | Windows 10 Professional, 10.0.19045 (22H2), x64
Bootstrapper | Claude Setup build 255293a41a25d54c5177aa9614fb4cd620e70b78
Target package | Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
MSIX SHA256 | ad5ead595fec1977c0ccb1d7fab3be040773b716451431dbd6bab457ba31a55c
Sideloading | enabled
S Mode | false
Developer mode | off
Log | C:\Users\<user>\AppData\Local\Temp\ClaudeSetup.log
<p>Every run downloaded the identical MSIX (same SHA256) and passed Authenticode
verification (<code>WinVerifyTrust: MSIX signature is valid</code>, <code>Signature verified: MSIX signer matches bootstrapper</code>). So this is not a download-integrity or signing problem — it is a
registration-stage failure gated on the leftover service.</p>
<p><code>0x80073CF6</code> = "Package could not be registered."
<code>0x80073CF9</code> = <code>ERROR_INSTALL_REGISTRATION_FAILURE</code> — "Install failed. Please contact
your software vendor."</p>
<h2>The core defect</h2>
<p>From the 08:44 run, elevated (<code>Is elevated: true</code>, <code>Elevation type: Full</code>):</p>
<pre><code>08:44:33.521786 WARNING: CoworkVMService already exists (potential conflict)
08:44:33.521786 Conflicting service: true
08:44:35.328479 Removing conflicting CoworkVMService...
08:44:35.329003 WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
08:44:35.329003 Checking for existing Claude MSIX packages...
...
08:44:35.357513 Installing via AddPackage (current-user)...
08:44:38.131311 MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
</code></pre>
<p>Three problems, in order of severity:</p>
<p><strong>1. The installer continues after a failed prerequisite.</strong> It knows the conflicting
service is still there. It knows removal failed. It proceeds to <code>AddPackage</code> regardless,
turning a known, nameable precondition failure into an opaque HRESULT.</p>
<p><strong>2. <code>OpenService</code> returns <code>Access is denied</code> in a fully-elevated context.</strong> This suggests
the service is running and/or its DACL denies <code>DELETE</code>/<code>SERVICE_STOP</code> to Administrators.
The installer does not appear to attempt <code>ControlService(SERVICE_CONTROL_STOP)</code> before
<code>DeleteService</code>, nor to enable <code>SeTakeOwnershipPrivilege</code> / adjust the SCM object's DACL.</p>
<p><strong>3. The error dialog names the wrong cause.</strong> The user sees:</p>
<pre><code>Administrator access is required to install Claude with full features.
You can try again or install without Cowork.
</code></pre>
<p>The installer <em>had</em> administrator access — the log says so on the line above. Retrying
does nothing, because the leftover service is still there. The dialog sends the user into
a loop of re-downloading a 247 MB package (four times in this log alone).</p>
<h2>Secondary defect: credentials are lost on every failed cycle</h2>
<pre><code>08:44:35.345714 Windows rejected data-preserving removal for Claude_1.34493.1.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
08:44:35.354512 Removing (user): Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
08:44:35.357513 Windows rejected data-preserving removal ... relying on in-place update
</code></pre>
<p><code>0x80073CFA</code> is <code>ERROR_REMOVE_FAILED</code>; <code>Remove-AppxPackage -PreserveApplicationData</code>
requires developer mode, which is off on this machine (and off by default for most users).
The installer falls back to "relying on in-place update" — but on the failure path the
in-place update never completes, and application data does not survive.</p>
<p><strong>User-visible consequence:</strong> the user is forced to sign in again after every failed
install attempt. This was the symptom they originally reported ("it keeps asking me to
sign in"), and they had no way to connect it to the installer. Repeated re-authentication
with no explanation reads to the user as an authentication bug.</p>
<h2>Steps to reproduce</h2>
<ol>
<li>On Windows 10 22H2 (developer mode off), install Claude Desktop with Cowork so that
<code>CoworkVMService</code> is registered.</li>
<li>Put the service into a state the installer cannot open for deletion — observed after a
prior failed/partial install, and reproduced after a reboot with the service running.</li>
<li>Run <code>Claude Setup.exe</code> and allow elevation.</li>
<li>Observe: <code>Conflicting service: true</code> → <code>failed to remove conflicting service: ... Access is denied</code>
→ <code>AddPackage failed with HRESULT 0x80073CF6</code> or <code>0x80073CF9</code> → the
"Administrator access is required" dialog.</li>
</ol>
<h2>Expected behavior</h2>
<ul>
<li>If the conflicting service cannot be removed, <strong>stop before calling <code>AddPackage</code></strong> and
show an actionable message naming <code>CoworkVMService</code>, with the remediation commands.</li>
<li>Attempt <code>ControlService(SERVICE_CONTROL_STOP)</code> and wait for <code>SERVICE_STOPPED</code> before
<code>DeleteService</code>. If the service is marked for deletion, tell the user a reboot is
required and offer to schedule it.</li>
<li>Never show "Administrator access is required" when <code>Is elevated: true</code> is in the log
three lines above. Surface the actual HRESULT and its meaning.</li>
<li>Preserve credentials across a failed install, or state plainly in the failure dialog
that the user will need to sign in again.</li>
<li>Document the Windows 10 22H2 support status for Cowork. If Cowork's virtualization
service is not supported on Windows 10, the installer should say so up front rather than
register a service it cannot later clean up.</li>
</ul>
<h2>Working user workaround</h2>
<p>Elevated PowerShell / cmd:</p>
<pre><code class="language-powershell">sc.exe query CoworkVMService
sc.exe stop CoworkVMService
sc.exe delete CoworkVMService
</code></pre>
<p>Reboot, then re-run the installer. In this log, both runs where the service was absent
(<code>Conflicting service: false</code>) installed successfully in under 20 seconds.</p>
<p>If <code>sc.exe delete</code> also returns access denied, the service DACL must be repaired
(<code>sc.exe sdset</code>) or the removal done from Safe Mode.</p>
<h2>Impact</h2>
<ul>
<li>Install fails with no actionable diagnostic; the dialog actively misdirects.</li>
<li>247 MB re-downloaded on every retry.</li>
<li>User is signed out repeatedly with no stated cause, which is the symptom they perceive
and report — not the install failure that causes it.</li>
</ul></body></html><!--EndFragment-->
</body>
</html>
Error Messages/Logs
Steps to Reproduce
s
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
s
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Terminal.app (macOS)
Additional Information
s
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗