When Cowork Stalls on Its First Task in Windows, Five Things I'd Check Before Touching Any Setting

One night I kept running into the same kind of report in a list of GitHub issues: Cowork installed on Windows, and the very first task never gets going. I work on a Mac, so I can't reproduce a Windows screen here, and I'll say that plainly up front.

What I did instead was read the official Windows checklist from the top and rebuild it into an order, cheapest check first. This is not a log of me fixing a Windows machine. It's a checklist drawn from the documentation, and I'd rather you read it that way.

The short version: look at how it was installed and what the machine can do before you touch any setting. Five checks cover most of it.

The official prerequisites, on one page

I used the checklist written for IT admins who roll Claude Desktop out to Windows fleets. Some wording differs from the personal-use pages, but the foundation for running Cowork is the same, so I kept only the overlapping parts.

The order follows how long each check takes. One and two are just a settings screen; from three on, restarts and admin rights come into play.

Checks 1 and 2: how it was installed, and which Windows

The first suspect isn't Cowork itself, but whether the app you installed is the kind that ships with Cowork. The checklist is explicit: only the .msix install gets Cowork, and the older .exe installer runs Claude Desktop without it.

To check, open Settings, then Apps, and see whether Claude is listed and where it came from. If you can't remember, reinstalling from the official download page was the quickest road.

Then look for S mode. Settings, System, About shows your Windows edition. Cowork doesn't run in S mode. Give these two checks three minutes, no more.

Check 3: is Virtual Machine Platform asleep?

Cowork runs the shell commands Claude issues inside a dedicated virtual machine the app manages on your device. So the machine has to be able to start a VM.

The documentation names two things: the Virtual Machine Platform Windows feature enabled (then a restart), and Intel VT-x or AMD-V switched on in firmware. Enabling the feature needs administrator rights; a standard user can't add it later.

Start by reading the state. In an elevated PowerShell:

# Run in an elevated PowerShell. This only displays the state; it changes nothing.
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform |
  Select-Object FeatureName, State

If State is Enabled, this item is fine. If it's Disabled, the checklist lists an enabling command, but it needs a restart, so save your work first.

Reading before enabling is my own line. If the feature is already on and the cause lies elsewhere, you've spent a restart for nothing.

Firmware screens differ by maker, so I can't cover them here. In Task Manager's Performance tab, a CPU panel that says "Virtualization: Enabled" usually means you're through.

Check 4: 20 GB free, and compressed folders

This is the one that's easy to miss. Per the docs, Cowork downloads its workspace the first time you start a task and keeps it on the drive that holds %LOCALAPPDATA%, hence the roughly 20 GB. Memory of 8 GB or more is the guide; with less it still starts, but tasks run slowly.

Also, the VM's disk can't start from a folder under NTFS compression or EFS encryption. On a personal PC that's rarely a worry. On a company-issued one, it's worth one look.

Open the folder's properties, then Advanced, and confirm that "Compress contents to save disk space" and "Encrypt contents to secure data" are both unchecked. If either is checked, don't uncheck it on your own; ask your administrator.

Check 5: is the helper being stopped?

If everything above holds and it still fails, the docs point at security software blocking claude.exe. It's a separate executable signed by Anthropic and placed under your user profile. Path-based allow rules can stop a file whose location isn't what the rule expected, I'd guess.

On a personal PC, look in your security software's blocked-items history for claude.exe. On a work PC where you can't see that, this is where you stop troubleshooting alone. One sentence to the admin is enough: "please allow claude.exe by publisher."

One more thing the docs mention: if the workspace download host (downloads.claude.ai) is unreachable, only the first task may stall. On a corporate network, keep that in the back of your mind.

Developer Mode: I wouldn't start there

After reading reports like these, it's tempting to think, "surely turning on Windows Developer Mode fixes it." Some articles say so. Yet the official checklist states that Windows Developer Mode is not required.

I haven't tried this on a Windows machine, so I can't tell you whether Developer Mode fixed anything. All I can say is that starting with settings the docs don't list as requirements tends to make isolation take longer.

Before fixing anything, put what the docs say is needed next to what they say isn't, on one page. That's the line I'm drawing here.

What to send if it still doesn't work

If the five checks don't settle it, the information you pass on can be short. These four are enough:

1. Which installer you used for Claude Desktop (.msix or .exe)
2. Your Windows version, and whether it's in S mode
3. The State of Virtual Machine Platform
4. Free space, and where it stopped (at launch, or partway through the first task)

For what to hand Cowork once it runs, see Write Access Came Third: The Order I Hand Folders to Cowork, and the companion note What you keep the agent from walking matters more than what you hand it.

Today, just check the installer type and S mode, and leave settings for after. Turning the checklist into a single table cut down my own hesitation, and I'd rather keep working that way.