Why Claude Cowork breaks before the work even starts
The repair kit for workspace failures, VM issues, network conflicts, and other problems most users still mistake for bad prompting.
Claude Cowork is now generally available on macOS and Windows, and Anthropic keeps widening what it can touch. Projects, scheduled tasks, Dispatch, OpenTelemetry, plugins, computer use. Cowork runs through Claude Desktop, uses an isolated virtual machine (basically a lightweight computer-inside-your-computer) for code and shell work, and stores its conversation history on your local machine. It is still excluded from the compliance tools enterprises normally rely on. Cowork activity does not appear in audit logs or the Compliance API, and it can’t be pulled through data exports. Anthropic’s own guidance says it directly: don’t use Cowork for regulated workloads.
That matters because a lot of users are still looking at the wrong layer when something breaks. A Cowork run fails, so they rewrite the task. They add more context. They start doing surgery on the prompt. But the actual problem is often somewhere else entirely. The workspace won’t start, or the VM service dies on launch, or a network rule blocks the connection before Claude even sees your files. Sometimes the session just got too broad too fast and now there’s no clean way to figure out what went wrong. Anthropic’s docs cover the product shape and the safety boundaries. The issue trackers and community reports show where things are actually falling apart in the field.
That gap between official docs and field reality is what this repair kit fills.
Why Cowork breakage feels different
Cowork is not a chat window with better memory. Anthropic describes it as Claude Code’s agentic capabilities brought into Claude Desktop for knowledge work beyond coding, with direct access to local files and MCP (Model Context Protocol) integrations running on your own machine. Projects are desktop-only and stored locally, with no cloud sync at this time.
This changes what failure looks like. In regular chat, when something goes wrong, you get a bad answer. You can see the problem in the output and course-correct. Cowork failures can happen before any answer exists. The host might not be ready. The workspace might fail during startup. A network rule might block the path before Claude even gets to your task. A plugin or unfamiliar MCP server might expand the task surface enough that figuring out what broke becomes a puzzle by itself. Anthropic’s safety docs spend real time on permissions, browser access, plugins, computer use, and cross-app movement because Cowork is attached to far more of your work surface than ordinary chat.
Once you see Cowork that way, the question changes. You stop asking “what prompt fixes this?” and start asking “what layer broke first?”
The four places underneath most Cowork failures
You don’t need a giant taxonomy. You need categories that change what you do next.
Host readiness
Anthropic tells users to keep Claude Desktop current and provides a Cowork readiness check you can download and run on supported machines. Cowork also depends on hardware virtualization, which is a feature your computer’s processor has to support and your operating system has to have enabled. People trying to run Cowork inside a virtualized Mac environment, for example, are hitting “virtualization not available” failures because you can’t easily nest one virtual machine inside another.
If the host isn’t ready, nothing you do to the task or the prompt matters. Fix the foundation first.
Network and routing
Anthropic’s own troubleshooting guidance for connection errors points straight at firewall rules, network restrictions, VPN interference, and proxy configuration. Users report the same pattern in Cowork startup failures, including getting a message that traffic may be routing through a VPN even when the VPN is supposedly off. Enterprise controls add another layer here. Anthropic’s IP allowlisting documentation (IP allowlisting is when a company restricts access so only approved network locations can connect) makes clear that requests from unapproved IP addresses get blocked, and affected users should talk to their IT department.
“Failed to start Claude’s workspace” is one of the most common errors people report, and it often gets misread as a task problem. A lot of the time, it’s a route problem. The connection between your machine and Anthropic’s servers isn’t completing.
Workspace and VM-state instability
This is where the field evidence gets rough.
Recent GitHub issues describe “VM service not running” errors and repeated workspace startup failures. Some users report RPC errors (remote procedure call, which is how different parts of the system talk to each other) tied to missing home directories. Others hit virtiofs or Plan 9 failures on Windows, which are the file-sharing protocols the VM uses to access your local files. In some cases restarting helps briefly but the error returns within minutes.
On Windows specifically, there’s a recurring problem worth knowing about. The Cowork VM service (called CoworkVMService) has its startup type set to manual, not automatic. That means after a reboot, a Windows update, waking from sleep, or sometimes for no clear reason at all, the service can quietly stay stopped and Cowork won’t launch. There have also been outages on Anthropic’s side affecting workspace creation, which is worth checking before you decide your laptop is the problem.
None of this is an official Anthropic root-cause diagnosis. But it tells you something useful: some Cowork failures are environmental and stateful. They live in the relationship between your operating system, the VM, the network path, and whatever services Windows or macOS need running in the background. They are not prompt-shaped. If you spend an hour editing instructions when the underlying system itself is unstable, that hour is gone.
Scope and surface-area sprawl
Anthropic’s safety guidance is clear about how fast Cowork’s reach can expand. Browser access through the Claude in Chrome extension introduces prompt-injection risk, where hidden instructions in web content can hijack what Claude does next. Computer use operates outside the VM and can interact directly with your apps and desktop. Plugins and local MCP servers expand what Claude can reach, and each one is a new path for untrusted content to enter the session. If Claude is active alongside the Excel and PowerPoint add-ins, it can move context between those applications without you explicitly directing the transfer. If you message Claude from your phone via Dispatch, your phone becomes a remote control for whatever file access, connectors, and plugins your desktop session already has.
The debugging consequence is simple: when the system is technically alive but your first retest includes all of these surfaces at once, you won’t learn anything from the result. A failure could be coming from any of them. You need to strip down before you build back up.
What paid subscribers get below
The rest of this article is the actual repair kit. It covers the recovery sequence that wastes the least time, the specific fixes (including the PowerShell commands for the Windows VM service problem and the network address range conflict that quietly kills Cowork on corporate networks), and six ready-to-use assets: a first-response checklist, a clean-room smoke test prompt, an incident capture template, a support escalation message for Anthropic, an IT escalation message for your company’s help desk, and a re-entry prompt for carefully widening scope after recovery.
The recovery sequence that wastes the least time
The goal is to separate layers fast so you know where the break actually lives.
Verify the host before you touch the task
Update Claude Desktop. If the machine is new or Cowork has been unstable, run the official readiness check. Anthropic provides a downloadable program for this. Use it. If you’re on managed hardware, remember that some failures are caused by policy, not by you. Admins can control access patterns through enterprise settings, network restrictions, allowlists, and (on Enterprise plans) role-based access controls with custom group permissions.
Run a clean-room task
Your first retest should be boring on purpose.
Use a brand-new local folder. Put one or two tiny trusted files in it. Do not reuse old project state. Do not connect Chrome, Slack, Excel, PowerPoint, Dispatch, plugins, or browser automation for this test. Anthropic’s own safety guidance recommends a dedicated working folder and a narrow starting point. Follow that advice here.
The clean-room task has exactly one job: tell you whether Cowork can start, read files, process them, and write an output.
A failure here means the prompt is not your main suspect. The problem is lower in the stack. But if the clean-room task completes without trouble, the next failure is probably hiding somewhere in the extra surface area you add back.
Fix the Windows VM service problem (if you’re on Windows)
If you’re on Windows and Cowork won’t start, check whether the CoworkVMService is actually running. Open PowerShell as an administrator and run:
Get-Service CoworkVMServiceIf the status shows “Stopped,” start it manually:
Start-Service CoworkVMServiceThen reopen Claude Desktop and try Cowork again. If this fixes the problem but it keeps coming back after reboots or sleep, that’s the manual startup type issue described above. It’s a known pattern and multiple GitHub issues track it. For now, the workaround is to start the service manually each time. You can create a shortcut or script to make this faster.
Simplify the network path
If the symptom looks like a startup failure, an API connection failure, trouble creating a workspace, or the app hanging during launch, strip the network down to something simple. Turn off the VPN. Remove unusual proxies. Try a different network if you can. If you’re on a work-managed machine, check with IT before assuming the product is broken.
Anthropic’s network troubleshooting guidance is clear on this, and on Windows specifically, there’s a second network issue worth knowing about. Cowork uses a hardcoded internal network address range (172.16.0.0/24) for communication between the VM and your machine. If your home network, corporate network, or VPN happens to use the same address range, the two will conflict and the VM won’t be able to reach the internet. This is like two houses on the same street having the same house number. Mail can’t get delivered. If you suspect this is your issue, the fix involves reconfiguring the Windows Host Network Service, which is detailed in community walkthroughs but requires some comfort with PowerShell.
This kind of investigation is less exciting than prompt iteration, but it’s also how you stop guessing.
Add back one variable at a time
Once the clean-room task works, resist the urge to reassemble your whole setup in one go.
Add back the folder you actually care about. Then your instructions. Then one connector. Then one plugin or one browser surface. Then the scheduled task. If something breaks after one of these additions, you know exactly what caused it because you only changed one thing. Anthropic’s safety docs are basically making this same argument about staged trust-building, even though they don’t frame it as debugging advice.
Capture evidence while the failure is fresh
The most useful support tickets are dull and specific.
Grab the exact error message. Note the time and your time zone. Record the Claude Desktop version, your operating system, whether the machine had recently woken from sleep, whether the task used local files, browser access, connectors, plugins, or phone Dispatch, and whether a VPN or corporate network was in the path. Anthropic’s support flow works like this: sign in, click your name or initials, choose “Get help,” and use the support messenger. Enterprise Owners and Primary Owners can also use the Enterprise Support form.
The difference between a support ticket that gets traction and one that doesn’t is usually this kind of detail. “It broke again” is a vent, not a report.
A note for team admins
If you’re running Cowork across a team rather than just your own machine, everything above still applies per-user, but you also need pattern detection across users to catch org-wide problems.
Anthropic now exposes usage analytics for Team and Enterprise plans, and the Enterprise Analytics API provides programmatic access to engagement and adoption data. OpenTelemetry (a monitoring standard your operations team may already use) goes further by letting security and operations teams stream Cowork events into their existing monitoring tools. Anthropic’s docs mention tool calls, file access, human approval decisions, and cost data as examples of what gets captured. That’s useful for spotting org-wide trouble after something changes, whether that’s a rollout, a policy update, a plugin install, or a Claude Desktop version bump.
But OpenTelemetry is not a compliance substitute. Anthropic says that directly. You can observe more now than you could six months ago. You still don’t have formal compliance-grade logging for Cowork activity.
Enterprise plans gained role-based access controls at GA, so admins can now organize users into groups (manually or through SCIM, which is an automated system that syncs user accounts from your company’s identity provider) and assign custom roles defining which Cowork capabilities each group can use. Team plans don’t have this. On Team plans, the Cowork toggle is still all-or-nothing for the whole organization. Know which plan you’re on before you assume you have granular controls.
The mistake that keeps recovery loops expensive
The expensive mistake is letting every failed session turn into an investigation where you’re trying to test everything at once.
You don’t need the first retest to prove Cowork can handle your whole week. You need it to prove one narrow thing: can this machine open a workspace, read a trusted folder, do something with the contents, and write one file back into that folder?
That’s enough to move forward.
My go-to recovery target is small on purpose. Two files in a clean folder, one short memo written back into the same directory, then stop. That single test tells you more than a sprawling task with browser tabs, plugins, scheduled runs, and four data sources stacked on top of each other.
Narrow workflows also tend to feel more trustworthy over time. They aren’t just easier to review. They give you a real signal when something breaks, because there are fewer places for the problem to hide.
Where this lands
Cowork failures are layered system failures, not prompt failures. Sometimes the task really is vague and sometimes the output design is weak, but Cowork is local enough and connected enough that a lot of the current breakage is happening below the prompt. Host readiness, routing, workspace state, surface sprawl, VM service quirks on Windows. Diagnose those in order, starting clean and adding complexity back one piece at a time. The goal is to stop spending time guessing at the wrong layer.
