Claude Desktop (Windows): provide a way to disable the bundled Cowork background service (CoworkVMService) for users who don't use Cowork

This is absolutely shady. I either have to uninstall Claude, or run my computer with cowork-svc.exe in memory at startup. Nasty

I noticed this today and came here as part of a search on the issue.
Agree with @itutar's analysis and recommendations.

Commenting here to keep issue fresh.

To deactivate Cowork, on Windows, I killed all Claude instances, then modified the `claude_desktop_config.json file by adding this in the "Preferences" section: "secureVmFeaturesEnabled": false,`. It then disabled the Cowork feature:

<img width="419" height="149" alt="Image" src="https://github.com/user-attachments/assets/02d2cf0b-f09e-4357-b60f-9da00dec9321" />

<img width="539" height="291" alt="Image" src="https://github.com/user-attachments/assets/dedc9d47-447b-4697-ba58-e4e739f0e9a4" />

This also allowed me to remove the "vm_bundles" folder that was taking more than 10Gb on the disk.

Hope it helps.

yeah this is pretty bs - if I configure claude not to run in the background, theres no reason this service should keep running

yeah this is pretty bs - if I configure claude not to run in the background, theres no reason this service should keep running

I mean there is the configuration fix which works as technically cowork doesn't work in the background. It just needs a surfaced configuration element in the app.

Another data point in favor of an off switch — CoworkVMService isn't just idle RAM, it actively broke the Claude Code CLI for me for a while.

Symptom (Desktop 1.13576.1.0, CLI 2.1.179, Win11 + Git Bash): intermittent No such file or directory / command not found from claude. A burst of claude --version failed 28/30.

Root cause: while running, the service re-runs npm install against the global CLI install on a loop, so ...\npm\node_modules\@anthropic-ai\claude-code\bin\claude.exe cycles: real ~225 MB native binary → ~500-byte placeholder stub → briefly absent. Any CLI invocation landing in one of those windows dies. Caught via a file-watch loop seeing the unlink/relink plus a staging dir node_modules/@anthropic-ai/.claude-code-<random>/ appearing mid-install. Not Defender, not the npm launcher shim, not the auto-updater.

Workaround: Stop-Service CoworkVMService (elevated) → 50/50 pass. Returns on reboot (StartType=Automatic). FWIW elevated Stop-Service works here even though sc.exe config ... start= disabled is blocked as you noted.

Update — looks fixed in a newer build. Re-tested today on Desktop 1.14271.0.0 / CLI 2.1.183: started the service, watched bin\claude.exe for ~85s (zero swaps, never stubbed), and ran 30× claude --version with the service running → 30/30 pass. Can't reproduce the binary-swap anymore.

So the acute breakage seems resolved, but it's a good example of why a user-facing way to disable the service (or trigger-only start) matters for Code-only users — when this regressed, the only mitigation was killing the service every boot.

agreed. This look fishy. Also the desktop control features? What actually Claude wants to do? Fishy

Title: Claude Desktop cowork/local-agent leaks Windows kernel non-paged pool (NTFS file-control-blocks, tag NtFC) without bound during workspace file activity → RAM exhaustion → host hard-freeze

Severity: High — full OS freeze requiring physical power-cycle (host-level, not just an app crash). Risk of data loss from forced resets.

Build: Claude Desktop (MSIX) Claude_1.14271.0.0_x64__pzs8sxrjxfjjc · Windows 11 · AMD Ryzen, 128 GB RAM · org 615dd87f-8efb-45aa-95e5-ccf929803c3c.

Summary: With cowork / local-agent mode enabled, Claude Desktop's local-agent performs heavy recursive file-system activity over its workspace folder(s). On the affected host this drove unbounded growth of Windows non-paged kernel pool — NTFS file-control-block (FCB) allocations, pool tag NtFC (ntfs.sys, Create.c): the agent opens/creates file handles far faster than the kernel releases them, with no cap or back-pressure, until physical RAM is exhausted and the host hard-freezes. The agent never self-limits or backs off. (The precise trigger inside the walker is unconfirmed — an early "self-referential symlink cycle" theory was disproven on investigation; see Evidence — but the unbounded NtFC accumulation and Claude Desktop being its source are confirmed.)

Evidence:

• claude.exe (main process) accumulated 345M+ file operations — ~150× any other process on the box.
• LiveKD !poolused 2: pool tag NtFC = 95.1M outstanding allocations, 14.2 GB, ntfs.sys (Create.c) = 99% of a non-paged pool that grew to 120 GB of 125 GB RAM at ~50 GB/hr, driving Available memory to ~0 and freezing the host. (Also surfaced as collateral 0x9F DRIVER_POWER_STATE_FAILURE and 0xA5 ACPI_BIOS_ERROR bugchecks — both STATUS_INSUFFICIENT_RESOURCES, i.e. downstream of pool starvation, not real driver/firmware faults.)
• taskkill /F /IM claude.exe /T → non-paged pool growth stops instantly (flat) — confirms Claude Desktop as the source.
• No filesystem cycle was found (the original "self-referential symlink" theory is disproven). On the affected host the only reparse point is a benign NTFS junction …\.claude\knowledge → …\knowledge that points to a sibling tree, not one of its own ancestors — so it can cause at most a one-time double-walk of a large directory, not an infinite loop. (…\knowledge\.claude is a real directory, not a link back; no link resolves to an ancestor.) Two conditions were unique to the affected host instead: (a) a large workspace tree — a ~100 MB, many-thousand-file git repo, reachable twice via that junction; (b) the host's cowork VM bundle was wedged (rootfs.vhdx missing + vmlinuz version mismatch), so every launch re-attempts a multi-hundred-MB bundle download that never completes — plausibly re-driving workspace scans in a retry loop. Whether (a), (b), or the combination drives the FCB accumulation is unconfirmed; the unbounded NtFC growth itself is not in doubt.

Three distinct defects:

1. No bound on file-handle / FCB accumulation in the local-agent. Its file scan opens NTFS file-control-blocks without any cap or back-pressure and doesn't release them promptly; it should cap outstanding handles, total files, and depth, with a safety cutoff. (Cycle-safe traversal — tracking visited reparse-point targets or device+file-id — is also warranted as defense in depth, though no cycle was required to trigger this leak.)
2. Local opt-out is ignored. Setting coworkScheduledTasksEnabled / ccdScheduledTasksEnabled = false in claude_desktop_config.json is overwritten back to true from account/org settings on the next launch — there is no way to disable cowork on a single machine.
3. Respawn watchdog. Force-killing claude.exe relaunches it (observed 8 procs → 3 respawn), so a user cannot stop the runaway without uninstalling.

Repro (observed; not yet minimally isolated): Enable cowork on a Windows host whose workspace contains a large tree (here: a ~100 MB git repo reachable twice via a sibling junction) and whose cowork VM bundle is in a broken / perpetually-re-downloading state (rootfs.vhdx missing, vmlinuz mismatch); launch Claude Desktop; watch \Memory\Pool Nonpaged Bytes climb without bound (poolmon/LiveKD !poolused shows tag NtFC, ntfs.sys). Killing claude.exe flatlines it. (A clean minimal repro isolating which factor is sufficient is still TODO.)

Requested fixes: (1) bound the local-agent's file activity — cap outstanding NTFS handles / total files / depth with back-pressure and a safety cutoff (the core fix); (2) cycle-safe directory traversal (visited reparse-point / device+file-id tracking) as defense in depth; (3) honor a per-machine local opt-out for cowork/local-agent; (4) do not auto-respawn claude.exe after a user force-kill; (5) when the VM-bundle refresh can't complete, fail cleanly instead of re-attempting an unbounded download/scan loop on every launch.

---

Update 2026-06-23 — related issue + how to disable

This is a known (less-severe) issue already filed: anthropics/claude-code#57371 — "provide a way to disable the bundled CoworkVMService for users who don't use Cowork" (opened 2026-05-08, Open). That issue covers the service can't be disabled angle (auto-starts, sc config→Access Denied, package-protected, registry Start=4 may break on update — all confirmed on Archie). Our case is far more severe than that issue describes (not "~12 MB idle RAM" — a 120 GB nonpaged-pool leak that hard-freezes the host). Best action: comment on #57371 with this pool-leak evidence + repro rather than filing fresh — it elevates severity on an existing thread.

How to disable Cowork (the only account-level lever): Owner/Primary Owner → Organization settings → Capabilities → Cowork → toggle off. Org-wide only — no per-user/per-machine granularity on Team plans (Enterprise can scope via groups/custom roles). So disabling it turns Cowork off on every machine on the org.

+1 — this needs attention.

I'm a paying Max subscriber who does not use Cowork and never will. My machine has virtualization disabled by deliberate choice, and I will not modify BIOS settings for a feature I don't want.

Consequences on my machine:

• A permanent, non-dismissible "Virtualization is not available" panel occupying my project screen
• Windows toast notifications instructing me to enable virtualization in my firmware
• A background service I cannot disable even as administrator

Worse: enabling virtualization wouldn't even guarantee relief. Issues #45715, #42227, and #45446 document users with virtualization fully enabled in firmware and Windows who still get this notice — the detection itself is broken. I'm being pressured to alter my BIOS for a feature I don't use, with no assurance the nagging would even stop.

I use Claude Desktop daily for a WordPress/WooCommerce business build — chat, projects, memory. None of it needs Cowork. There is no toggle, no dismiss, no opt-out. Please implement any of the proposed solutions — trigger-only service, in-app toggle, or optional install.

Now it bitches if you disable the service too with "Failed to start Claude’s workspace
VM service not running. The service failed to start.
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace or share your debug logs to help us improve."

Guess I'm uninstalling this spyware

+1 Confirming this architectural concern from a fresh Windows inspection.

On this machine, CoworkVMService is registered as a packaged Win32 service with:

• TYPE : 210 WIN32_PACKAGED_PROCESS
• START_TYPE : 2 AUTO_START
• SERVICE_START_NAME : LocalSystem
• binary path under the Claude MSIX package (...\\WindowsApps\\Claude_<version>_x64__pzs8sxrjxfjjc\\app\\resources\\cowork-svc.exe)

The package manifest also declares both:

• a desktop6:Service entry with StartupType="auto" and StartAccount="localSystem"
• a custom trigger tied to \\pipe\\cowork-vm-service

So this does not look like malware or a hidden persistence trick; it looks like a standard packaged service chosen by the app. The concern is the product/architecture choice: the service already has an on-demand trigger path, yet it is also placed in the boot path with LocalSystem privileges even for users who may never use Cowork.

From a Windows least-privilege / user-control perspective, trigger-only start would be a much better default. If boot-time startup is genuinely required for specific Cowork features, those should be documented clearly in-app and users should have an explicit way to disable the service when they do not use Cowork.

This is especially confusing because it does not appear in the ordinary Startup Apps surface, so many users will not realize Claude has installed a boot-time privileged background service unless they inspect Services or the package manifest directly.

I have been noticing for a week or more that Claude is and keeps running in the background on windows in process explorer, even though I disabled 'Run on Startup'. It keeps turning it back on. Off means off, and this has eroded my trust severely. I don't understand how Github #48078 has been closed, since it is very much still alive.

Adding a working user-side workaround in case it helps others while this is open.

The trigger is already registered and intact:

PS> sc.exe qtriggerinfo CoworkVMService
SERVICE_NAME: CoworkVMService
        START SERVICE
          CUSTOM                       : 1f81d131-3e60-4c76-9860-37334e4ffce3 [ETW PROVIDER UUID]
            DATA                       : \pipe\cowork-vm-service

(sc.exe prints the generic ETW label, but that GUID is the well-known NAMED_PIPE_EVENT_GUID.)

Taking ownership turned out to be unnecessary on my machine, the HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService already grants Administrators Full Control via inheritance from MACHINE\SYSTEM. What's blocked is sc.exe / Set-Service, by the SCM's packaged-service protection, not the registry ACL. So writing the value directly from an elevated prompt just works:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name "Start" -Value 3
Stop-Service -Name "CoworkVMService" -Force

After a reboot, Get-Service CoworkVMService reports Status: Stopped, StartType: Manual, and cowork-svc.exe is no longer in the boot path.

Start=3 rather than 4 on purpose: 4 would disable the trigger as well, so Cowork could never start on demand. With 3 the declared named-pipe trigger stays in place. (I haven't tested on-demand start by actually launching Cowork, but the trigger registration is untouched.)

This is still a per-machine registry edit, and I'd expect MSIX re-registration on the next app update to reset Start back to 2, so it needs re-checking after updates. Which is really the argument for proposal 1 above: the trigger is already declared in the manifest and the service clearly functions without StartupType="auto", so dropping auto-start looks like a small, safe change.

+1. Chat and Code are all I use — the ~10 GB Cowork VM is pure overhead for my workflow. Please make it an optional component at install time, or add an uninstall/remove action for the VM bundle. A chat/Code-only install path would solve this cleanly.

Time to use chatgpt to make a patcher so this shit can be removed fully

+1 on this request. I'd like to add some context on why I think this deserves higher priority than a typical "add a toggle" feature request.

The core issue is a consent gap, not just a missing convenience feature.

On Windows, users can disable Claude Desktop's startup behavior through two legitimate, OS-sanctioned channels:

• Windows Settings → Apps → Startup
• Task Manager → Startup tab

Both correctly show the app as Disabled, and both stay Disabled. That's the expected contract: the user made a choice, and the OS respects it.

However, CoworkVMService (running as cowork-svc.exe under localSystem) sits outside that contract entirely. It's registered as a background Windows service with StartupType="auto", independent of the app-level startup toggle. So a user who has explicitly turned off startup — through the correct, documented UI — still ends up with a SYSTEM-level process launching on every boot.

What makes this worse than a typical background-service quirk is that there's currently no user-accessible path to opt out:

• services.msc shows the startup type as grayed out / non-editable for this service.
• Set-Service / sc.exe from an elevated PowerShell session returns access denied, because the service is registered as part of the MSIX package with permissions that exclude standard admin-level service management.

In effect, the only way to stop it is an unsupported registry-level workaround (manually flipping the start type to 4/Disabled outside any sanctioned UI), which is not something a general user should have to resort to, and which may not survive app updates.

Why I'd frame this as a consent/trust issue rather than pure UX polish:

A background service running as localSystem that (a) starts automatically regardless of a setting the user explicitly turned off, and (b) cannot be disabled through any first-party, documented mechanism, is a meaningful gap for privacy- and security-conscious users — including in managed/enterprise environments where IT admins expect to be able to enforce a "no background services without explicit opt-in" policy. Right now there's no supported way to guarantee that.

I'd support any of the fixes already proposed upthread — trigger-only startup via manifest change, an in-app toggle that actually stops+disables the service, or making Cowork an optional/uninstallable component — but I'd like to flag that from a trust standpoint, item 2 (an in-app toggle backed by real permission to stop the service) seems like the minimum bar, since it's the only option that gives users a supported, persistent way to say no without relying on registry hacks.

Also commenting here to keep issue fresh.

This is not okay behavior, regardless of microslop and others having the same bs practices, it isn't right to force a user to run resource hijacking services without consent.

<html>
<body>
<!--StartFragment--><html><head></head><body><h2>Comment for #57371 — Windows Server 2022 confirmation, plus downstream impact on Claude Code CLI</h2>
<p>Adding a data point from <strong>Windows Server 2022 Standard</strong> — this isn't limited to Windows 11 desktop installs.</p>
<h3>Environment</h3>
<ul>
<li><strong>OS</strong>: Windows Server 2022 Standard</li>
<li><strong>Access method</strong>: Remote (RDP)</li>
<li><strong>Claude Code version</strong>: unknown — <code>claude --version</code> itself hangs (see below), so I couldn't retrieve it</li>
<li><strong>Other Claude products installed</strong>: Claude Desktop / Cowork appears installed on this machine (<code>cowork-svc.exe</code> visible in Task Manager, <code>CoworkVMService</code> confirmed via <code>Get-Service</code>)</li>
</ul>
<h3>What's Wrong</h3>
<p>Claude Code sessions repeatedly stop responding with the error:</p>
<blockquote>
<p><strong>Claude Code stopped responding</strong>
Try sending your message again.
<em>The session stopped responding. Send your message again to resume with a fresh process.</em></p>
</blockquote>
<p>Each time this occurs, Task Manager shows the total Claude-related process count climbing rather than old processes being cleaned up:</p>

Observation | Process count
-- | --
1st occurrence | 16
2nd occurrence (after clicking "Try again") | 19
3rd occurrence (after full manual kill + relaunch) | 21

<p>In each snapshot, exactly <strong>3 "Claude Code" processes</strong> are seen consuming ~12.7–12.8% CPU each, alongside a growing number of dormant "Claude" processes consuming between 4–430+ MB of memory each, plus matching orphaned <code>conhost.exe</code> entries.</p>
<p>Total memory footprint reached <strong>~822 MB and 40% system CPU</strong> across the process group by the 3rd occurrence, despite no active user interaction (session was reportedly idle — "have not yet done anything yet and its eating up resources already").</p>
<p>Even a full <code>taskkill /F /IM claude.exe /T</code> followed by a clean relaunch did not prevent the issue from recurring shortly after.</p>
<p>Additionally, <code>/doctor</code> itself hung indefinitely (1m 40s+, no output) during one troubleshooting attempt, suggesting the diagnostic command is also affected rather than just regular chat.</p>
<h3>Steps to Reproduce</h3>
<ol>
<li>Launch Claude Code in a project directory on Windows Server</li>
<li>Begin a normal chat session</li>
<li>Session becomes unresponsive to input, including Ctrl+C</li>
<li>Observe Task Manager: process count for Claude Code/Claude has increased since last check, with 3 active "Claude Code" processes pinned at ~12.8% CPU</li>
<li>Dismiss error, click "Try again" or relaunch — process count increases further rather than resetting</li>
</ol>
<h3>Expected Behavior</h3>
<ul>
<li>A single <code>claude.exe</code> process (or a bounded, known set) should represent one session</li>
<li>Old/crashed processes should be automatically cleaned up rather than accumulating</li>
<li><code>/doctor</code> should complete or fail fast rather than hang indefinitely</li>
<li>Ideally, Claude Code would warn on startup if orphaned processes from previous sessions are still running (similar to the proposal in #11122)</li>
</ul>
<h3>Workaround (current)</h3>
<pre><code class="language-powershell">taskkill /F /IM claude.exe /T
</code></pre>
<p>Then relaunch. This only provides temporary relief — the issue recurs after continued use.</p>
<h3>Confirmation of the access-denied behavior described in this issue</h3>
<p>Same result as reported here, confirmed independently:</p>
<pre><code>PS&gt; sc.exe config CoworkVMService start= disabled
[SC] OpenService FAILED 5:
Access is denied.
</code></pre>
<p>This failed even from a fully elevated "Administrator: Windows PowerShell" session (confirmed via title bar), not just an unelevated one — so this isn't a UAC issue, it's the package-level ACL described in this issue.</p>
<p><code>sc.exe sdshow CoworkVMService</code> output on this machine:</p>
<pre><code>D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
</code></pre>
<p><code>Set-Service -StartupType Disabled</code> also failed identically with <code>PermissionDenied: (System.ServiceProcess.ServiceController:ServiceController) [Set-Service], ServiceCommandException</code>.</p>
<h3>Downstream impact: this also breaks Claude Code CLI, not just Cowork/Claude Desktop</h3>
<p>Worth flagging that this isn't only a "Cowork tab won't disable" annoyance — on this server, the inability to control <code>CoworkVMService</code> had a knock-on effect on <strong>Claude Code CLI</strong>, which is presumably a separate product:</p>
<ul>
<li><code>claude --version</code> and <code>/doctor</code> both hang indefinitely (no timeout, requires Ctrl+C) rather than failing fast</li>
<li>Repeatedly killing <code>claude.exe</code> (<code>taskkill /F /IM claude.exe /T</code>) does not help — new <code>claude</code> processes reappear under <strong>different PIDs</strong> almost immediately, consistent with <code>CoworkVMService</code> respawning them</li>
<li>Task Manager showed the Claude-related process count climbing across troubleshooting attempts (16 → 19 → 21 processes), with 3 "Claude Code" processes consistently pinned at ~12.8% CPU each, and total memory footprint reaching ~822 MB / 40% system CPU while the machine was otherwise idle</li>
<li>Network connectivity to <code>api.anthropic.com:443</code> was confirmed working (<code>Test-NetConnection</code> succeeded), ruling out firewall/proxy as the cause</li>
<li><code>.claude.json</code> config file was small (402 bytes) and <code>.claude</code> folder was empty, ruling out config corruption/bloat as the cause</li>
</ul>
<p>So on a machine where the Cowork service can't be disabled, it appears to actively interfere with independent Claude Code CLI sessions rather than just sitting inert in the background. If that's expected (e.g., some shared locking/coordination by design), it'd be good to document; if not, it seems like a second bug worth tracking separately.</p>
<h3>Workaround used</h3>
<pre><code class="language-powershell">Stop-Service -Name CoworkVMService -Force
taskkill /F /IM claude.exe /T
</code></pre>
<p>This works but doesn't persist — the service is set to auto-start, so it needs to be repeated each session/reboot, matching what's already described in this issue.</p>
<p>Happy to provide <code>/heapdump</code> diagnostics or additional Task Manager screenshots if useful for triage.</p>
<h3>Cross-referenced issues</h3>
<ul>
<li>#32792 — multiple claude.exe processes spawn with no process guard (Windows)</li>
<li>#42169 — claude.exe accumulates virtual memory, never releases it, zombie processes from crashed sessions</li>
<li>#55482 — claude-cli exhausts system resources spawning multiple processes</li>
<li>#11122 — feature request for process visibility/management (<code>claude ps</code>, <code>claude kill</code>, idle timeout, startup warning)</li>
</ul></body></html><!--EndFragment-->
</body>
</html>

Ended up here because I noticed that setting the "Run at startup" parameter to Off in the General settings of Claude Desktop app for Windows, does not work: when I re-open the settings panel after switching it off, it is still On...
This was reported in the following ticket, but that's now closed with "Not planned": https://github.com/anthropics/claude-code/issues/48078
Then Claude directed me to this ticket here....

Not a fix and decidedly not sufficient to solve this problem, but you can hijack the service with your own, either nssm or as a scheduled task.
Script that polls every 5s and sets the service to manual, then kills proc if claude isn't open.

$regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService"
$svcName = "CoworkVMService"
$claudeProc = "Claude"   
$logFile = "$env:TEMP\cowork-svc-monitor.log"

while ($true) {
    # enforce Start=3
    $current = (Get-ItemProperty -Path $regPath -Name "Start").Start
    if ($current -ne 3) {
        Set-ItemProperty -Path $regPath -Name "Start" -Value 3 -Type DWord
        Add-Content -Path $logFile -Value "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')  Reverted Start=$current -> forced 3"
    }

    # kill service if running without Claude
    $svc = Get-Service -Name $svcName -ErrorAction SilentlyContinue
    if ($svc.Status -eq "Running") {
        $claudeRunning = Get-Process -Name $claudeProc -ErrorAction SilentlyContinue
        if (-not $claudeRunning) {
            Stop-Service -Name $svcName -Force
            Add-Content -Path $logFile -Value "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')  Service running without Claude -> stopped"
        }
    }

    Start-Sleep -Seconds 5
}

Can add as scheduled task, place the above code at: C:\ClaudeCOWORKServiceGuard\cowork-guard.ps1
Then in admin powershell to add the startup task, use AT OWN RISK, this is admin PS after all:

$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File C:\ClaudeCOWORKServiceGuard\cowork-guard.ps1"
$trigger = New-ScheduledTaskTrigger -AtStartup
$settings = New-ScheduledTaskSettingsSet -RestartCount 999 -RestartInterval (New-TimeSpan -Minutes 1) -ExecutionTimeLimit ([TimeSpan]::Zero)
Register-ScheduledTask -TaskName "CoworkGuard" -Action $action -Trigger $trigger -Settings $settings -User "SYSTEM" -RunLevel Highest -Force
Start-ScheduledTask -TaskName "CoworkGuard"

Confirm running:

Get-ScheduledTask -TaskName "CoworkGuard" | Select TaskName, TaskPath, State

Confirm active/working:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name "Start" -Value 2 -Type DWord
#wait 5s
 Get-Content "C:\Windows\Temp\cowork-svc-monitor.log" -ErrorAction SilentlyContinue
# expect to see Reverted Start=2 -> forced 3

Commenting to keep this issue fresh. Cowork takes up 10 GB even though I don't use the feature.

will be there SOME answer from anthropics? Its not like its free open source service. We actually paid for this stuff! At least answer something

Sorry for not being advanced in tech terms but thanks to cowork-svc.exe i cant use normal claude desktop app without closing whole windows since somehow cowork is open on the background without claude being open. And because its a process with system access i cant close it via powershell or cmd which makes it so im required to close my pc and leave my work half done since i cant access to claude properly.

<img width="336" height="114" alt="Image" src="https://github.com/user-attachments/assets/8ae38a82-e5c2-49f8-aeec-d8880ff3fedc" />

IU have the same issue as ronovatr. This is really annoying.