I run dozens of scheduled Claude Cowork tasks overnight so I can wake up and step straight into the day instead of building the day first. The morning I found Claude Cowork not working after a Windows update, a pile of those overnight tasks had failed, and it cost me real time before I understood what happened. On September 10, 2026, I woke up to my computer sitting on the Windows login screen, Claude not running, and a two-day backlog of updates that had installed themselves while I slept.
The error one of them threw was "Bash is wedged after 5 identical mount failures." The shell underneath it said something more specific and more alarming: "sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared." My first instinct was that the task was doing something wrong, because nothing else on the machine looked broken.
That instinct was the mistake. The task was fine. A single Windows cumulative update, KB5124008, had broken Claude Cowork's local shell across every session on the machine. This is the whole story: what actually broke, how I ruled out the wrong suspects, how I found the culprit, and the one step that fixed it. If you are on Windows and your Cowork tasks suddenly cannot run a command, skip to the fix.
Key takeaways
-
A Windows 11 cumulative update, KB5124008 (build 26200.9445), broke Claude Cowork's ability to run shell commands on my PC. Reading and writing files still worked, which is exactly why the problem hid so well.
-
Cowork on Windows runs shell commands inside a small local Linux VM and reaches your files by mounting your drive into that VM. The VM was booting fine. The drive share was never getting attached, so every command failed before it even ran.
-
It was not one bad task. The app logs showed 57 failed shell calls across 15 different sessions in a single morning. The whole machine had lost its shell.
-
Uninstalling the update and rebooting fixed it immediately. Every folder mounted again, and every library came back.
-
The fix path if it happens to you: Settings, Windows Update, Update history, Uninstall updates, remove the newest cumulative update, reboot.
-
Windows 11 Home only lets you pause updates for five weeks, then it force-installs. That five-week ceiling is how this landed on me in the first place.
What actually broke?
Claude Cowork could no longer run a shell command on any task, in any session on the machine. Reading and writing files still worked, so most of the app looked completely healthy while the part that runs code was dead.
Here is the piece that makes it click. Cowork on Windows does not run Linux commands directly on Windows. It boots a small Linux virtual machine on your PC and runs the commands in there, and it reaches your actual files by mounting your C: drive into that VM as a shared folder. The VM was starting up normally that morning. The network was up, the SDK was installed, and startup took about seven seconds. The one thing that was not happening was the drive share getting attached, and without it, the shell had nothing to stand on. Every command failed before it ran, with that "no Plan9 drive shares mounted" line.
File reads and writes travel a different path than the shell does, which is why editing and saving kept working the whole time. That split is the reason I wasted my first hour blaming the task. From inside the app, almost everything looked fine.
How did I know it was the whole machine and not one task?
The app logs. They gave a precise count that no amount of staring at a single failed task would have.
When I pulled the Cowork logs, the morning had 57 failed shell calls spread across 15 different sessions. I run a lot of scheduled tasks, and nearly every one of them had quietly hit the same wall while I was asleep. That number is what reframed the whole thing. One task failing is a task problem. Fifteen sessions failing the identical way, with the identical error, is an infrastructure problem, and the automation I was about to go rewrite had nothing wrong with it.
The logs live in two files if you ever need them: cowork_vm_node.log and main.log, both under %LOCALAPPDATA%\Claude\Logs. Between them, they told the whole story in a few minutes once I stopped guessing and actually read them.
What did I rule out first?
Rebooting, my cloud-synced work folder, and the Windows virtualization stack, in that order. All three were dead ends, and ruling them out is what pointed the finger at the update.
Fully quitting the app and rebooting the whole PC did nothing, which already told me this was not a stuck process. Support's first suggestion was that the Google Drive sync on my working folder might be the cause, so I tested with a plain local folder with no sync on it at all. It failed exactly the same way. The next suggestion was the Windows virtualization stack, the layer that lets the Linux VM exist. I checked it: VirtualMachinePlatform was enabled, the Hyper-V services were running, and Windows reported an active hypervisor. All healthy.
The last thing that mattered was that nothing on Claude's side had changed. The app version and the VM bundle were both untouched since September 8, and they had worked fine on the 8th and the 9th. When the software has not changed, and it stops working overnight, the thing that changed is underneath it.
How did I find the actual cause?
Two timestamps and Windows Update history. The logs pinned the exact window the shell died in, and the update log showed the one thing that landed inside it.
The last successful shell command ran at 11:38 pm on September 9. The first failure hit at 8:45 am on September 10. That is a tight window, and Windows keeps a receipt for everything it installs. My update pause had expired, so Windows had spent that window force-installing a two-day backlog it had been holding: Dell firmware, a stack of Intel drivers, the August cumulative update, and then, on the 8:38 am reboot, the September 2026 cumulative update, KB5124008, plus a .NET security update, KB5126052.
Everything except those last two predated my last known-good shell run, so they were not the suspects. It came down to the two that installed on that final reboot, seven minutes before the first failure. KB5124008 is the September 2026 Patch Tuesday cumulative update for Windows 11, build 26200.9445 on 25H2, which is what I am running.
What was the fix for Claude Cowork not working after the Windows update?
Uninstall KB5124008 and reboot. That was the entire fix, and it worked instantly.
I tried the smaller thing first and removed the .NET update, KB5126052, on its own. That did nothing. Then I uninstalled KB5124008 and restarted, and the shell came back on the first boot. Every folder mounted, Python and curl were back; every library the tasks depend on was there again. One monthly Windows cumulative update had taken out Cowork's local shell, and pulling that one update put it back.
If you are staring at the same thing, here is the click path. Open Settings, go to Windows Update, open Update history, scroll to the bottom and click Uninstall updates, remove the newest cumulative update, and reboot. Cowork runs fine on Windows the rest of the time, so if the shell dies overnight and nothing in your setup changed, a fresh update is the first place I would look now.
How do you keep it from happening again?
Pause updates, and put a reminder on the calendar to deal with it before the pause runs out. On Windows 11 Home, that is the only real lever you have, and it is a short one.
Windows Home only lets you pause updates for five weeks before it force-installs whatever it has been holding. That five-week ceiling is the actual root cause of my morning, because the pause expiring is why a two-day backlog dumped itself on me overnight in the first place. I paused updates again, this time until October 15, and I put a reminder on the calendar for October 12 to check with Anthropic support for a real fix and re-pause if there is not one yet.
I also reported the whole thing to support with the logs and the exact KB number, because a monthly Windows update is not a rare edge case. If this update does what it did to me on other Windows machines running Cowork, anyone who takes it could hit the same wall, and the people it hits will do exactly what I did and blame their own task first.
Frequently asked questions
Why did Claude Cowork stop running commands after a Windows update?
On my machine, the September 2026 Windows 11 cumulative update KB5124008 broke the drive share that Cowork's local Linux VM uses to reach your files. The VM still booted, but the shell had no mounted files to work with, so every command failed before it ran. Reading and writing files still worked because that uses a different path than the shell.
How do I fix Claude Cowork not working on Windows?
In my case, the fix was to uninstall the offending Windows cumulative update and reboot. Open Settings, go to Windows Update, open Update history, click Uninstall updates at the bottom, remove the newest cumulative update, and restart. The shell came back on the first boot.
Was it Claude or Windows that broke Cowork?
Windows. The Claude app version and the Cowork VM bundle had not changed and had worked fine the two prior days. The only thing that changed overnight was a batch of Windows updates, and removing the newest cumulative update fixed it.
What is the "no Plan9 drive shares mounted" error in Cowork?
It means the local Linux VM that Cowork uses could not attach your drive as a shared folder, so the shell has no files to operate on. The VM itself is running. The mount that connects it to your files is not, which is why commands fail instantly while file reads and writes still work.
Can I stop Windows 11 Home from force-installing updates?
You can pause updates, but only for about five weeks on Windows 11 Home, after which it installs the backlog automatically. The practical move is to pause and set a calendar reminder before the pause expires so a large backlog does not land all at once while you are away from the machine.
How do I know if one Cowork task is broken or the whole app is?
Check the logs. On Windows, they live at %LOCALAPPDATA%\Claude\Logs in cowork_vm_node.log and main.log. If you see the same shell failure across multiple sessions rather than one, the problem is under the app, not in the task you happened to be looking at.
Final thoughts
The lesson I took from this is not really about Windows. It is that when an automation fails with an error that sounds like plumbing, the first question is whether anything else on the machine is failing the same way, before you touch the automation itself. I burned my first hour rewriting a task that was working perfectly, because a single failure in front of me looked like a single problem. The logs showed 57 of them, and the whole picture changed in one line.
The other half is that the fragile part of an automation is almost never the part you built. The task ran for months. What broke it was a routine update to the operating system underneath it, arriving on a schedule I do not fully control, on a reboot I was asleep for. You can write the cleanest agent in the world and still get taken out by the floor moving under it.
The best part, and the reason I can even write this up in detail, is that the entire diagnosis happened inside a Cowork chat, with Claude reading its own app's logs off my PC to find the update that had broken its own shell. When the floor moves, at least you can ask the thing standing on it what it felt.
Interested in learning more?
For more on the operator side of building and running AI agents, take a look at How to Build an AI Agent for Shopify Product Pages and How We Let an AI Agent Earn Autonomy One Action at a Time.
If you like using AI to chase down a stubborn technical problem, Outlook Cannot Display the Folder? Here's the Real Fix (I Used AI to Find It) is the same instinct pointed at a different bug. For the judgment call of when to reach for a heavier tool, there is When to Use a More Powerful AI Model: The Two Days I Wasted Going Cheaper.
