claude-code - 💡(How to fix) Fix Claude Desktop (Windows): provide a way to disable the bundled Cowork background service (CoworkVMService) for users who don't use Cowork

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

  • No in-app toggle in Claude Desktop to disable Cowork or its background service.
  • Standard Windows methods are blocked because it's an MSIX-packaged service:
    • sc.exe config CoworkVMService start= disabled returns OpenService FAILED 5: Access is denied, even from an elevated Administrator PowerShell.
    • Set-Service -StartupType Disabled has the same problem.
  • The package manifest hardcodes <desktop6:Service Name="CoworkVMService" StartupType="auto" StartAccount="localSystem">, so even a clean reinstall would re-register it identically. Uninstalling Claude Desktop is not an option for me — I use it daily.
  • The only workarounds are user-hostile: take ownership of HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService and force Start=4, or schedule a Stop-Service task at logon. Both may break on package updates and feel wrong on a system level.

Fix Action

Fix / Workaround

  • No in-app toggle in Claude Desktop to disable Cowork or its background service.
  • Standard Windows methods are blocked because it's an MSIX-packaged service:
    • sc.exe config CoworkVMService start= disabled returns OpenService FAILED 5: Access is denied, even from an elevated Administrator PowerShell.
    • Set-Service -StartupType Disabled has the same problem.
  • The package manifest hardcodes <desktop6:Service Name="CoworkVMService" StartupType="auto" StartAccount="localSystem">, so even a clean reinstall would re-register it identically. Uninstalling Claude Desktop is not an option for me — I use it daily.
  • The only workarounds are user-hostile: take ownership of HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService and force Start=4, or schedule a Stop-Service task at logon. Both may break on package updates and feel wrong on a system level.

There is no acceptable user-side workaround.

Code Example

<desktop6:Extension Category="windows.service"
  Executable="app\resources\cowork-svc.exe"
  EntryPoint="Windows.FullTrustApplication">
  <desktop6:Service
    Name="CoworkVMService"
    StartupType="auto"
    StartAccount="localSystem">
    <desktop6:TriggerEvents>
      <desktop6:DataItem Value="\pipe\cowork-vm-service" />
      ...
    </desktop6:TriggerEvents>
  </desktop6:Service>
</desktop6:Extension>

---

PS> sc.exe config CoworkVMService start= disabled
[SC] OpenService FAILED 5:

Access is denied.

---

Name        : CoworkVMService
DisplayName : Claude
Status      : Running
StartType   : Automatic
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

On Windows, Claude Desktop bundles a packaged Win32 service called CoworkVMService (running app\resources\cowork-svc.exe as localSystem) inside its MSIX package. The service is registered with StartupType="auto" and starts on every system boot — even when the user has never opened Cowork or has decided not to use it.

I'm primarily a Claude Code user. I tried Cowork once early on, decided Claude Code suits my workflow better, and haven't used Cowork since. But cowork-svc.exe still spins up on every boot, takes RAM, and there is no way to turn it off:

  • No in-app toggle in Claude Desktop to disable Cowork or its background service.
  • Standard Windows methods are blocked because it's an MSIX-packaged service:
    • sc.exe config CoworkVMService start= disabled returns OpenService FAILED 5: Access is denied, even from an elevated Administrator PowerShell.
    • Set-Service -StartupType Disabled has the same problem.
  • The package manifest hardcodes <desktop6:Service Name="CoworkVMService" StartupType="auto" StartAccount="localSystem">, so even a clean reinstall would re-register it identically. Uninstalling Claude Desktop is not an option for me — I use it daily.
  • The only workarounds are user-hostile: take ownership of HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService and force Start=4, or schedule a Stop-Service task at logon. Both may break on package updates and feel wrong on a system level.

Separate but related issue: the Claude Desktop in-app Run on startup toggle (Settings → General desktop settings) does not persist when toggled off — switching to another tab in Settings and back shows the toggle back ON without the user touching it. (In Windows Settings → Apps → Startup and Task Manager's Startup tab, Claude is correctly Disabled and stays Disabled. The persistence bug is only inside Claude Desktop's own Settings UI.)

Proposed Solution

Any one of these would solve the core problem:

  1. Change the service to trigger-only in the package manifest — drop StartupType="auto" so the service only spins up when the user actually invokes Cowork, and stays out of the boot path otherwise. The manifest already declares trigger events (\pipe\cowork-vm-service), so this should be a small change.
  2. Add an in-app toggle in Claude Desktop Settings: Enable Cowork background service (default ON). When OFF, the app stops the service and keeps it from auto-starting on next boot. Because user-side sc.exe can't modify packaged services, this needs to be done by code shipping inside the package (which has the rights).
  3. Make Cowork an optional component at install time, or expose an Uninstall Cowork component action for users who only use Claude Code CLI / Claude Desktop chat.

Also, please fix the in-app Run on startup toggle so the OFF state persists across tab navigation and app restarts.

Alternative Solutions

What I currently do (none of these are real solutions):

  • Take ownership of HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService and force Start=4 — risky and may be reverted on package update; also feels wrong to modify package-protected registry from the user side.
  • Schedule a Stop-Service CoworkVMService task at user logon — service still spins up on every boot, just gets killed within a couple seconds. Wastes resources.
  • Manually stop the service in services.msc each boot — won't survive reboot, has to be repeated daily.

There is no acceptable user-side workaround.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

  1. I install Claude Desktop on Windows 11.
  2. Out of curiosity I open Cowork once, decide it's not for my workflow, and stop using it. (Or alternatively: I never open Cowork at all.)
  3. From that point on, every time my computer boots, Task Manager → Processes shows a "Claude" group containing cowork-svc.exe running as a service, consuming ~12 MB.
  4. I look for a way to stop it: no in-app toggle, Windows Settings → Apps → Startup doesn't list it (only the main Claude executable, which I've already disabled), Services.msc shows it but sc.exe refuses to change StartupType because the service is package-protected.
  5. End state: I either give up and let it run forever, or I become a Windows admin to take ownership of the service registry key — which feels disproportionate for a feature I don't use.

With the proposed change (trigger-only service or in-app toggle), step 3 onwards goes away.

Additional Context

Environment

  • Claude Desktop version: 1.6259.1.0
  • Claude Desktop package family: Claude_pzs8sxrjxfjjc
  • Service: CoworkVMServiceapp\resources\cowork-svc.exe, runs as localSystem
  • OS: Windows 11
  • Reproducible on: any Claude Desktop install where the user doesn't use Cowork.

Manifest snippet (from AppxManifest.xml)

<desktop6:Extension Category="windows.service"
  Executable="app\resources\cowork-svc.exe"
  EntryPoint="Windows.FullTrustApplication">
  <desktop6:Service
    Name="CoworkVMService"
    StartupType="auto"
    StartAccount="localSystem">
    <desktop6:TriggerEvents>
      <desktop6:DataItem Value="\pipe\cowork-vm-service" />
      ...
    </desktop6:TriggerEvents>
  </desktop6:Service>
</desktop6:Extension>

Trigger events are already declared, so trigger-only start (without StartupType="auto") should be feasible.

Reproduction of the sc.exe lockout (elevated PowerShell):

PS> sc.exe config CoworkVMService start= disabled
[SC] OpenService FAILED 5:

Access is denied.

Get-Service CoworkVMService:

Name        : CoworkVMService
DisplayName : Claude
Status      : Running
StartType   : Automatic

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Claude Desktop (Windows): provide a way to disable the bundled Cowork background service (CoworkVMService) for users who don't use Cowork