If Claude Cowork stopped running local commands on your Windows machine after September 8, there is a fix. Microsoft shipped patch KB5129195, which restores the Plan9 filesystem behavior that the earlier update broke. Go to Settings > Windows Update > Check for updates, install what appears, then run winver to confirm your build reads 26200.9457 or 26100.9457. That is the short version. The rest of this article explains exactly what happened, why it happened, and what to do if the patch does not fully resolve things for your setup.
What the September 8 Update Actually Did
Windows 11 security updates KB5124008 (x64) and KB5124012 (ARM64) shipped on September 8 and introduced a breaking change to the Hyper-V Plan9 filesystem layer. The updates were positioned as routine security releases, which is why many teams applied them without hesitation. The failure mode that followed was not immediately obvious, and that caused a frustrating diagnostic gap before the root cause became clear.
The Plan9 filesystem protocol, sometimes written as 9P, is the mechanism Windows uses to share host-side directories into Linux guest environments running inside HCS-managed virtual machines. WSL 2 relies on it. Claude Cowork relies on it. Any tool that needs a Linux runtime with access to your Windows file system goes through this layer.
The specific change introduced by KB5124008 and KB5124012 altered how Hyper-V handled token-backed Tattach requests. A Tattach request is part of the 9P handshake that establishes a filesystem connection between the Linux guest and the Windows host. After the update, those token-backed requests were rejected with an EINVAL error, which is a generic "invalid argument" response at the kernel level. The guest environment received the rejection and could not complete the mount. Without a mounted host filesystem, the Linux environment was essentially isolated.
The consequence was that Claude Cowork could no longer execute local commands. The tool needs to read, write, and interact with files on your actual machine to do its job. When that path is severed, the agentic layer of Claude Cowork stops working. Notably, as Windows Latest reported when Microsoft acknowledged the issue, basic chat and simple file reading or editing sometimes continued to function. That partial functionality made diagnosis harder, because the tool appeared to be running while its most powerful capabilities were silently broken.
WSL users hit the same wall. Any workflow that depended on WSL 2 mounting Windows drives, which is the default behavior for most WSL 2 installations, failed the same way. The EINVAL error showed up in different forms across different tools, but the underlying cause was identical: the Plan9 sharing layer was rejecting the attachment requests.
Why This Update Caused Such a Wide Failure
Security updates that touch virtualization infrastructure carry inherent risk, because the surface area is large and the interactions are deep. The Plan9 implementation sits at a low level in the Hyper-V stack, and a change there propagates upward through every tool that depends on it. The fact that KB5124008 and KB5124012 were security-focused updates, not feature updates, meant they received less pre-release scrutiny from developers building on top of WSL and HCS. Teams that test their tooling against Windows Insider builds often catch this kind of regression earlier, but security patches do not always surface in Insider channels with enough lead time to matter.
The breadth of the failure is also why Microsoft moved relatively quickly on a fix. When a single update breaks WSL, Claude Cowork, and other Linux VM tooling simultaneously, the signal volume is high and the affected population is visible. The GitHub issue thread on the Anthropic Claude Code repository became a live aggregation point for affected users, which helped surface the pattern fast.
How Claude Cowork Uses the Plan9 Layer (And Why It Matters)
Claude Cowork is not a simple chatbot wrapper. It is an agentic coding environment that needs real access to your local filesystem to operate. Understanding that architecture explains why this particular Windows update hit so hard, and why partial functionality during the outage was so confusing.
When Claude Cowork runs on Windows, it operates inside a Linux environment managed through WSL 2 or a compatible HCS-managed VM. That Linux environment is where the Claude agent process lives, where commands execute, and where file operations happen. The agent reads your source code, writes changes, runs tests, and interacts with your project directory, all from within that Linux context.
The bridge between that Linux context and your actual Windows files is the Plan9 filesystem share. Windows exposes your drives (typically mounted at /mnt/c or similar paths inside the Linux environment) via the 9P protocol. Every time Claude Cowork reads a file from your project, writes a result, or checks a directory structure, that operation crosses the Plan9 bridge.
When KB5124008 broke the Tattach handshake, that bridge collapsed. The Linux environment could still start. The Claude process could still run. Basic operations that did not require reaching across to the Windows host could still complete. But the moment any operation needed to touch a file on your Windows drive, it hit the broken mount and failed.
This is also why the fix had to come from Microsoft rather than Anthropic. The break was at the OS infrastructure level, below anything Claude Cowork or WSL could work around in software. Anthropic could not patch their way out of a kernel-level filesystem rejection.
The Difference Between Chat Working and Cowork Working
A number of users reported that Claude Cowork "sort of worked" after the update, which is accurate but misleading. The conversational interface, the part where you type a prompt and receive a response, runs through a different path than local command execution. If you were asking Claude questions that could be answered from its training or from content you pasted directly into the chat, those requests did not need to cross the Plan9 bridge and so they completed normally.
The failure only became apparent when you asked Claude to do something that required touching your filesystem: read a file, run a shell command, inspect a directory, execute a test suite. Those requests hit the broken mount and either errored out silently or returned confusing failure messages that did not point directly at the underlying cause.
For teams using Claude Cowork for real work across marketing and technical roles, this partial failure mode was particularly disruptive because it was not obvious that the tool was broken rather than misbehaving.
The Fix: Installing KB5129195
Microsoft's patch KB5129195 restores the Plan9 filesystem sharing behavior that KB5124008 and KB5124012 disrupted. Installing it moves your system to OS Build 26200.9457 (for most consumer and commercial devices) or 26100.9457 (for certain hardware configurations). Both builds have the corrected Plan9 implementation.
The process for getting the fix is straightforward:
- Open Settings. Press the Windows key, type "Settings," and open the Settings app.
- Navigate to Windows Update. In the left sidebar, select "Windows Update."
- Check for updates. Click the "Check for updates" button. If KB5129195 is available for your device and has not already been applied automatically, it will appear here.
- Install and restart. Download and install the update, then restart your machine when prompted.
- Verify your build. After restarting, press Windows + R, type
winver, and press Enter. The dialog that appears will show your current OS Build. Confirm it reads 26200.9457 or 26100.9457. If it does, the fix is applied.
As PC Magazine confirmed when covering Microsoft's rollout of the fix, KB5129195 was designed specifically to address the Plan9 virtual machine sharing breakdown, and the build numbers above are the reliable confirmation that the correct patch is installed.
What If the Update Does Not Appear?
In some cases, Windows Update may not immediately surface KB5129195 even though your machine is affected. This can happen for several reasons: your device may be managed by a corporate update policy that delays patch distribution, Windows Update may have encountered a download error, or your machine may already be on a build that received the fix through a different update path.
If the update does not appear after checking for updates, try these steps in order:
- Restart Windows Update by opening the Services app (search "services" in the Start menu), finding "Windows Update," right-clicking, and selecting "Restart." Then check for updates again.
- If you are on a work-managed device, contact your IT administrator. Corporate update policies sometimes require manual approval or deployment through a device management platform before patches appear on individual machines.
- Run the Windows Update Troubleshooter: Settings > System > Troubleshoot > Other troubleshooters > Windows Update.
- Check whether your current build is already at 26200.9457 or 26100.9457 via
winver. If it is, the fix is already present regardless of whether you see KB5129195 listed in your update history.
If Claude Cowork Is Still Broken After Patching
A small number of users report that Claude Cowork does not immediately recover even after KB5129195 is successfully installed and the build number confirms the patch is in place. This is not a sign that the patch failed. It usually indicates that the WSL or VM environment needs to be reset after the filesystem layer is restored.
Work through these steps in sequence before assuming the patch did not take effect:
Step 1: Confirm Your Build Number
Run winver and verify the build number. Do not assume the patch installed correctly based solely on the Windows Update interface. The build number is the authoritative confirmation. If the build does not match 26200.9457 or 26100.9457, the patch has not applied and you should restart the update process.
Step 2: Shut Down and Restart WSL
Open PowerShell or Command Prompt as Administrator and run:
wsl --shutdown
Wait ten seconds, then open a new WSL terminal. This forces WSL to reinitialize the 9P filesystem connection from scratch rather than resuming from a cached state that may have been established during the broken period.
Step 3: Check Whether WSL Can Mount the Host Drive
Inside a WSL terminal, run:
ls /mnt/c
If this command returns a directory listing of your C drive contents, the Plan9 mount is working. If it returns an error or an empty result, the mount is still broken and the underlying issue has not been resolved. At that point, note your exact OS Build number from winver and report it, along with the WSL error output, to your IT administrator or to the support channels for Claude Cowork.
Step 4: Test a Simple Cowork Command
After confirming the WSL mount is working, open Claude Cowork and run a simple local command, such as asking it to list the files in a specific directory on your machine. If this succeeds, local command execution has been restored and the fix is complete.
Step 5: Check for Conflicting Group Policies
On managed corporate devices, Group Policy settings can affect how Hyper-V and WSL behave independently of the OS build version. If you are on a domain-joined machine and WSL is still failing after the patch, ask your IT team to verify that the Hyper-V policy settings have not been locked in a way that prevents the Plan9 layer from operating correctly after the update.
WSL Users: The Same Fix, the Same Path
WSL 2 and Claude Cowork were broken by the same mechanism and are fixed by the same patch. If you are a developer who uses WSL 2 for work unrelated to Claude Cowork, the steps above apply equally to you. The Plan9 filesystem restoration in KB5129195 covers all HCS-managed virtual machines, not just those running Claude Cowork.
The WSL failure manifested in a few different ways depending on the specific workflow. Some users saw explicit mount errors when starting a WSL session. Others found that their WSL environment started cleanly but /mnt/c was empty or inaccessible. Others still saw intermittent failures where some file operations succeeded and others did not, which points to a race condition in the broken attachment handshake.
After applying KB5129195 and running wsl --shutdown followed by a fresh WSL session, the mount should restore automatically. The ls /mnt/c test above is the reliable check. If WSL is still not mounting your Windows drive after the patch and the shutdown cycle, the next diagnostic step is to check the Windows Event Viewer (search "Event Viewer" in the Start menu, navigate to Windows Logs > Application) for Hyper-V or WSL-related errors that appeared around the time of the failed mount attempt. Those logs can pinpoint whether the issue is in the 9P layer itself or in a higher-level configuration problem.
For teams building internal tools and automation on top of WSL, this kind of OS-level disruption is a reminder that investing in structured Claude Code knowledge pays off precisely when things break, because you understand the architecture well enough to diagnose problems rather than waiting for someone else to fix them.
Understanding the Plan9 / 9P Filesystem in Plain Terms
The Plan9 filesystem protocol is the technical backbone of how Windows and Linux coexist on the same machine in WSL 2 and similar virtualization environments. You do not need to understand it deeply to fix this problem, but a working mental model helps you anticipate future issues and understand why this break was so disruptive.
WSL 2 runs a real Linux kernel inside a lightweight Hyper-V virtual machine. That virtual machine is isolated from Windows by default, which is what makes it fast and secure. But isolation creates a problem: your Linux tools need to access files on your Windows drive, and a fully isolated VM cannot do that.
The solution Microsoft implemented is a filesystem server that runs on the Windows side and speaks the Plan9 protocol. The Linux guest connects to that server using 9P over a virtual socket, and the Windows host translates those filesystem requests into native NTFS operations. From the Linux side, it looks like a normal mounted filesystem. From the Windows side, it is a translation layer that converts Linux file requests into Windows file operations.
The Tattach request that KB5124008 broke is part of the initial handshake that establishes this connection. "Tattach" is the 9P protocol term for "attach to a filesystem tree," which is the step where the Linux client says "I want to access this directory" and the Windows server responds with a handle that the client can use for subsequent operations. When the update caused those token-backed Tattach requests to return EINVAL, the handshake failed at step one and no mount could be established.
The "token-backed" qualifier matters because not all Tattach requests are token-backed. Simple, unauthenticated mounts do not use tokens. But the mounts used by WSL 2 and HCS-managed VMs use security tokens to establish that the Linux guest is permitted to access the host drive. That authentication step is what the update inadvertently broke, and it is also why only certain filesystem operations failed while others appeared to work normally.
Why This Is a Recurring Risk Area
The Plan9 / 9P integration layer is a relatively young piece of Windows infrastructure compared to the rest of the OS. Microsoft added it specifically to support WSL 2, and it has been refined incrementally since WSL 2 launched. That means it is more likely to be affected by security updates that touch the Hyper-V stack than older, more stable subsystems would be.
This is not a criticism of the approach. The design is sound and generally works well. But it does mean that Windows developers and power users who rely on WSL 2 or HCS-managed VMs should monitor their WSL functionality after major security updates, particularly those that touch Hyper-V components. A quick ls /mnt/c after any significant Windows Update takes ten seconds and can catch this kind of regression immediately.
The Timeline: From Break to Fix
Understanding the timeline of this incident helps calibrate how quickly Microsoft moved and what the practical disruption window looked like for most affected users.
| Date | Event | Impact |
|---|---|---|
| September 8 | KB5124008 (x64) and KB5124012 (ARM64) ship as routine security updates | Plan9 Tattach break introduced; WSL and Claude Cowork begin failing on updated machines |
| September 8–11 | User reports accumulate on GitHub, forums, and support channels | Pattern becomes clear; root cause identified as Plan9 / EINVAL failure |
| September 12 | Microsoft publicly acknowledges the issue | Official confirmation that KB5124008 and KB5124012 are responsible |
| Post-acknowledgment | KB5129195 ships; moves affected PCs to Build 26200.9457 or 26100.9457 | Plan9 sharing restored; WSL and Claude Cowork recover after patch and WSL restart |
The window between the break and the fix was measured in days rather than weeks. For a low-level virtualization issue affecting a large number of users, that is a reasonably fast turnaround. The speed of the response was partly driven by the visibility of the problem: when WSL breaks, the signal reaches Microsoft's engineering teams quickly because the affected user base is loud and technically articulate.
What This Means for Teams Running Claude Cowork at Scale
This incident is a useful forcing function for teams that have adopted Claude Cowork as a core part of their workflow. A tool that sits at the intersection of OS-level virtualization, a third-party AI runtime, and your local development environment has more failure points than a simple web application. That is not a reason to avoid it, but it is a reason to build some operational awareness around it.
A few practical adjustments are worth making in the wake of this incident:
Test After Every Major Windows Update
The ls /mnt/c check takes ten seconds. Running it after any significant Windows Update, particularly those that touch Hyper-V or virtualization components, gives you immediate confirmation that the Plan9 layer is intact. If it fails, you know immediately rather than discovering the problem mid-project when a Claude Cowork command inexplicably does nothing.
Know Your Build Number
Knowing how to run winver and read the result is a basic diagnostic skill that pays off disproportionately in situations like this. When a fix ships and the guidance says "confirm you are on Build 26200.9457," being able to check that immediately tells you whether you need to take action. It takes less than thirty seconds and removes all ambiguity.
Monitor Relevant GitHub Issues
The Anthropic Claude Code GitHub repository is where infrastructure issues like this surface earliest and get diagnosed fastest. Watching or subscribing to relevant issue threads gives you advance notice of problems before they affect your team. The September 8 issue was visible in the repository within hours of the update shipping.
Have a Fallback for Critical Moments
If Claude Cowork is central to your workflow, it is worth knowing what you would do if it became unavailable for a day. For most teams, that means having the Claude web interface available as a fallback for tasks that do not require local command execution. It is not a full replacement, but it covers the conversational and reasoning use cases while a local tooling issue is being resolved.
Teams that have invested in structured Claude Code training tend to navigate these disruptions better, because they understand which capabilities require local infrastructure and which do not. If your team is still building that foundation, it is worth addressing proactively rather than discovering the gaps during an incident. Understanding where your team actually stands is the first step, and there are clear signals that indicate when structured training is overdue.
Frequently Asked Questions
What exactly is KB5124008 and why did it break Claude Cowork?
KB5124008 is a Windows 11 security update for x64 systems that shipped on September 8. It introduced a change to the Hyper-V Plan9 filesystem-sharing implementation that caused token-backed Tattach requests to be rejected with an EINVAL error. Because Claude Cowork depends on the Plan9 layer to give its Linux runtime access to your Windows files, the broken Tattach handshake prevented local command execution. The ARM64 equivalent is KB5124012, which caused the same failure on ARM-based Windows 11 machines.
Is KB5124012 the same issue as KB5124008?
Yes. KB5124008 is the x64 (standard Intel/AMD) version of the September 8 security update, and KB5124012 is the ARM64 version. Both introduced the same Plan9 filesystem change and both caused the same Tattach rejection failure. Both are resolved by installing KB5129195.
How do I know if my machine is affected?
If you updated Windows 11 on or after September 8 and Claude Cowork stopped being able to run local commands while chat still worked, your machine is very likely affected. You can confirm by opening a WSL terminal and running ls /mnt/c. If that command fails or returns nothing, the Plan9 mount is broken and you need KB5129195.
What build number should I be on after installing the fix?
After KB5129195 installs successfully, running winver should show OS Build 26200.9457 (for most devices) or 26100.9457 (for certain hardware configurations). Either build confirms the fix is in place.
Claude Cowork is still not working after I installed the patch. What do I do?
First, confirm your build number via winver to make sure the patch actually applied. Then run wsl --shutdown in an elevated PowerShell or Command Prompt, wait ten seconds, and open a fresh WSL terminal. Test with ls /mnt/c. If the mount is now working, restart Claude Cowork and try a local command. If WSL is still not mounting correctly after all of this, note your exact build number and any error messages you see in the WSL terminal, and report them through the official support channels.
Is this a Claude Cowork bug or a Windows bug?
This is a Windows bug. The failure is in the Hyper-V Plan9 filesystem layer, which is OS infrastructure that Microsoft owns and maintains. Claude Cowork depends on that layer but has no ability to fix or work around a break at that level. The fix had to come from Microsoft, and it did, in the form of KB5129195.
Does this affect WSL even if I do not use Claude Cowork?
Yes. Any WSL 2 environment or HCS-managed virtual machine that needs to access the Windows host filesystem is affected by the same Plan9 break. The fix, KB5129195, restores the functionality for all affected use cases, not just Claude Cowork.
Will uninstalling KB5124008 fix the problem?
Rolling back the September 8 update is technically possible through Windows Update history, but it is not the recommended path. KB5124008 is a security update, and removing it reintroduces the vulnerabilities it addressed. The correct path is to install KB5129195, which preserves the security improvements while restoring the Plan9 functionality. Only consider a rollback in an emergency, and treat it as a temporary measure until the fix patch can be applied.
My company manages Windows updates centrally. How do I get the fix?
Contact your IT administrator and ask them to deploy KB5129195. On managed corporate devices, Windows Update patches are typically approved and distributed through a device management platform such as WSUS, Intune, or SCCM. Your IT team will need to approve and push the patch before it appears on your machine. Provide them with the build number target (26200.9457 or 26100.9457) so they can confirm deployment.
How can I prevent this kind of disruption in the future?
The most reliable preventive measure is to test your WSL mount after every significant Windows Update by running ls /mnt/c in a WSL terminal. If that fails immediately after an update, you have caught a regression before it disrupts real work. Monitoring the Anthropic Claude Code GitHub repository for infrastructure-related issues also gives early warning when problems emerge.
Does this affect Claude Cowork on Mac or Linux?
No. The Plan9 filesystem issue is specific to Windows 11 and the Hyper-V / HCS virtualization stack. Claude Cowork on macOS uses a different virtualization approach and is not affected by this update. Linux native installations do not use Hyper-V at all.
What is the Plan9 filesystem and why does Claude Cowork need it?
Plan9 (also written 9P) is a network filesystem protocol that Windows uses to share the host drive with Linux environments running inside WSL 2 and HCS-managed virtual machines. Claude Cowork runs its agent process inside a Linux environment, and it needs access to your Windows files to read code, write changes, and execute commands. The Plan9 layer is what makes that cross-environment file access possible. When it breaks, the agent loses access to your files and local commands stop working.
Key Takeaways
- The cause: Windows 11 security updates KB5124008 (x64) and KB5124012 (ARM64), which shipped September 8, broke the Hyper-V Plan9 filesystem layer by rejecting token-backed Tattach requests with an EINVAL error.
- The impact: Claude Cowork lost the ability to run local commands. WSL 2 mounts failed the same way. Basic chat often continued working, which made the failure mode confusing to diagnose.
- The fix: Microsoft shipped KB5129195. Install it via Settings > Windows Update > Check for updates. Confirm with
winverthat your build reads 26200.9457 or 26100.9457. - If still broken after patching: Run
wsl --shutdown, reopen WSL, and test withls /mnt/c. If that mount fails, report your exact build number and WSL error output. - Preventive habit: Run
ls /mnt/cin WSL after any major Windows Update to catch Plan9 regressions immediately. - Managed devices: Ask your IT administrator to deploy KB5129195 through your organization's update management platform.
Get Hands-On With Claude Cowork Before the Next Disruption Catches You Off Guard
Incidents like this one reveal a gap that has nothing to do with the bug itself. Teams that understand how Claude Cowork is architected, what it needs from the OS, and where its dependencies sit can diagnose and recover from infrastructure failures in minutes. Teams that treat it as a black box spend hours wondering why chat works but commands do not.
AdVenture Media runs live Claude Code workshops designed for professionals who want to move past surface-level usage and build real operational fluency with these tools. Whether your team is just getting started or already running Claude Cowork on production workflows, the sessions cover the architecture, the failure modes, and the practical patterns that make the difference between using the tool and depending on it confidently.
If that sounds useful, the current schedule and registration details are at adventuremedia.ai/workshops.
Join our live Claude Code workshops and training events
Learn more →
