Your Claude Cowork session stopped executing local commands. Chat still loads. Files still open. But the moment Cowork tries to run anything against your local filesystem, nothing happens. If that describes your Windows 11 machine right now, you are not dealing with a Claude bug, a network issue, or a broken install. A Windows 11 security update that shipped on September 8th quietly severed the filesystem bridge that Claude Cowork depends on, and until you apply Microsoft's patch, the connection stays broken.
The good news: there is a fix, it is already in Windows Update, and it takes about two minutes to apply. The rest of this article explains exactly what happened under the hood, why it hit Claude Cowork and WSL at the same time, and what the Plan9 filesystem has to do with any of it. Understanding the mechanism matters, because the same architecture underpins a growing number of AI-assisted development tools, and knowing how the plumbing works helps you diagnose faster the next time something like this surfaces.
Fix First: How to Restore Claude Cowork on Windows 11 Right Now
The fix is a single Windows Update: KB5129195. Once installed, your PC moves to OS Build 26200.9457 or 26100.9457, Plan9 filesystem sharing is restored, and Claude Cowork resumes executing local commands normally. Here is the exact path to apply it.
Step-by-Step Fix
- Open Settings (Windows key + I).
- Navigate to Windows Update.
- Click Check for updates. If KB5129195 is available, it will appear in the list. Allow it to download and install.
- Restart your machine when prompted.
- After restart, press Windows key + R, type
winver, and press Enter. Confirm the build number reads 26200.9457 or 26100.9457. Either build confirms the fix is in place.
Most machines will see the update offered automatically, but Windows Update sometimes staggers rollouts. If the update does not appear immediately, clicking "Check for updates" manually forces the check against Microsoft's servers rather than waiting for the scheduled background scan.
If you have already installed KB5129195 and Claude Cowork still will not execute local commands, the diagnostic priority is to confirm whether WSL (Windows Subsystem for Linux) is also affected. Open a PowerShell terminal and run wsl --status or simply try launching a WSL distribution. If WSL is also broken after the patch, note your exact OS Build number from the winver dialog and open a support thread, because that points to a secondary issue beyond the Plan9 fix.
According to the PC Magazine coverage of the patch rollout, KB5129195 specifically restores the Plan9 sharing mechanism that the September 8th update broke. The fix is targeted and does not roll back the underlying security changes in KB5124008 or KB5124012.
What Broke: The September 8th Update and the Plan9 Connection
Windows 11 security updates KB5124008 (for x64 systems) and KB5124012 (for ARM64 systems) went live on September 8th and changed how the Hyper-V Plan9 / 9P filesystem-sharing implementation handles authentication. Specifically, the update caused token-backed Tattach requests to be rejected with an EINVAL error. That single change was enough to break the entire filesystem bridge between the Windows host and Linux guest environments running inside HCS-managed virtual machines.
To understand why that matters for Claude Cowork, it helps to understand what Plan9 and 9P actually are, and why they ended up at the center of Windows 11's Linux integration story.
What Is the Plan9 Filesystem?
Plan 9 from Bell Labs was an operating system developed in the 1980s and 1990s as a successor to Unix. Its most influential idea was a principle called "everything is a file," taken further than Unix ever did. In Plan 9, the network, processes, devices, and remote resources were all exposed through a unified filesystem namespace. You accessed a remote machine's files the same way you accessed local ones, through a protocol called 9P (sometimes written as 9P2000 in its modern form).
Plan 9 itself never achieved mainstream adoption, but 9P as a protocol survived and became widely used precisely because of its simplicity and its ability to mount remote filesystems efficiently. The protocol is lightweight, stateful, and well-suited to the kind of environment where a Linux guest needs to reach a Windows host's filesystem without going through a full network stack.
Microsoft's engineering team chose 9P as the foundation for filesystem sharing in WSL 2 and in the HCS (Host Compute Service) virtual machine architecture that powers it. When you access your Windows C: drive from inside a WSL session, the data travels over a 9P channel managed by Hyper-V's Plan9 implementation. The same channel is what Claude Cowork uses when it needs to read, write, or execute files on the host machine from within its Linux guest environment.
What Is a Tattach Request?
In the 9P protocol, a Tattach message is the handshake that attaches a client (the Linux guest) to a specific file tree on the server (the Windows host). Think of it as the authentication and connection step that must succeed before any file operations can happen. Without a successful Tattach, the guest cannot mount the host filesystem at all. No mount, no filesystem access. No filesystem access, no local command execution.
The September 8th update changed the way the Hyper-V Plan9 implementation validates tokens during the Tattach phase. Token-backed Tattach requests, which are the type used in the HCS virtual machine context, started being rejected with an EINVAL error. EINVAL is a standard POSIX error code meaning "invalid argument," so from the Linux guest's perspective, the filesystem mount was simply failing with an invalid argument error, giving no indication that a Windows security update on the host side was the root cause.
As Windows Latest reported on September 12th, Microsoft acknowledged publicly that the September update was breaking multiple features, with the Plan9 filesystem issue being among the most impactful.
Why Did Chat and File Reading Still Work?
This is the part that confused a lot of users, and understandably so. If the filesystem bridge was broken, why did Claude Cowork's chat interface still load? Why could some users still open and read files?
The answer is that Claude Cowork's architecture separates concerns. Chat and conversational functions operate through network connections to Anthropic's API, which have nothing to do with the Plan9 filesystem channel. Basic file reading, in some configurations, can also work if files are being passed through the API layer rather than accessed directly via the mounted filesystem.
What stopped working was anything that required Claude Cowork to execute commands directly on the host machine through the Linux guest environment. Shell commands, build operations, file writes to locations that required the mounted drive, and any workflow that depended on the guest accessing the host's filesystem all failed. The break was surgical in that specific way: the API surface stayed up, but the local execution layer went dark.
This distinction also explains why some users initially dismissed the problem as intermittent or minor. If their Claude Cowork usage leaned heavily on conversation and light file review, they might not have noticed anything wrong for days. Users running automated pipelines, build processes, or any workflow that depended on local command execution hit the wall immediately.
You can trace the detailed thread of user reports and technical analysis at the GitHub issue opened on the Anthropics Claude Code repository, where affected users documented the EINVAL errors and narrowed the cause to the September 8th update.
The HCS Virtual Machine Architecture: Why This Matters Beyond Claude Cowork
The Host Compute Service (HCS) is Microsoft's virtualization management layer that sits between Windows 11 and the Hyper-V hypervisor. It is what WSL 2 uses to run Linux distributions, and it is what Claude Cowork's local execution environment depends on. Understanding HCS explains why this bug hit so many tools simultaneously and why the filesystem sharing architecture is more fragile than it appears on the surface.
HCS and the Lightweight VM Model
HCS manages what Microsoft calls "utility VMs" or lightweight virtual machines. These are not full desktop VMs with graphical interfaces and independent OS installs. They are stripped-down Linux environments, usually running a Microsoft-maintained kernel, optimized for fast startup and low resource consumption. The tradeoff for that efficiency is deep integration with the Windows host, particularly around filesystem access.
In a traditional full VM setup running in something like VMware or VirtualBox, filesystem sharing is typically handled through a completely separate mechanism, often a virtual network adapter and SMB shares. The guest and host are more isolated. In the HCS model, the Plan9/9P channel is built directly into the Hyper-V virtualization layer, which is why it is fast and seamless but also why a change to the Hyper-V Plan9 implementation has immediate and widespread consequences.
Every tool that relies on this architecture, including WSL 2, the Windows Subsystem for Android, and developer tools like Claude Cowork that embed a Linux runtime, shares the same Plan9 channel. A breaking change at the Hyper-V layer does not just break one application. It breaks the entire class of applications that depend on HCS-managed filesystem sharing.
Why Security Updates Touch Virtualization Code
Security updates to the Hyper-V stack are not unusual. Hyper-V runs at a privilege level below the OS itself, making it a high-value target for isolation bypass attacks. Microsoft regularly ships patches that tighten validation and authentication in the hypervisor layer.
The September 8th update appears to have introduced stricter validation of the token-backed authentication mechanism used in Plan9 Tattach requests. The intent was presumably to harden the filesystem sharing channel against potential abuse. The result was that the validation was strict enough to reject requests that legitimate tools were making, causing widespread breakage that Microsoft had not anticipated.
This is not an unusual pattern in operating system development. Security hardening that changes authentication behavior at a low level has a long history of creating unexpected breakage in software that was working correctly against the old behavior. The challenge is that the failure mode in this case was silent from the user's perspective. No error dialog appeared. Claude Cowork did not display a message saying "Plan9 mount failed." The local execution layer simply stopped working, and users had to piece together the cause themselves.
What This Means for Teams Running AI Development Tools on Windows
If your team uses Claude Cowork, Claude Code, or any other AI-assisted development tool that runs a Linux guest environment on Windows 11, this incident is worth understanding as an architectural dependency, not just a one-off bug. The Plan9 channel is the bridge between the AI tool's execution environment and your actual files and processes. Changes to that bridge, whether from security updates, Windows version upgrades, or Hyper-V configuration changes, can break the tool in ways that are not immediately obvious.
For teams using Claude Cowork to run marketing automation, content pipelines, or internal tool development (the kinds of workflows detailed in our piece on how founders are using Claude Code to build internal tools), an unexpected break in local command execution can halt a workflow without any obvious error message pointing to the cause. Building awareness of the HCS architecture into your team's mental model helps you triage faster when something like this happens again.
How the Plan9 Filesystem Windows 11 Architecture Actually Works
For professionals who want more than a surface-level explanation, this section walks through the actual data path that the Plan9 filesystem takes on Windows 11, from a Claude Cowork command request all the way to the host filesystem and back. This is the architecture that KB5124008 disrupted and KB5129195 restored.
The Data Path: From Claude Cowork to Your Files
When Claude Cowork executes a local command that requires filesystem access, the request flows through several layers before it touches an actual file on your Windows drive.
First, the command is issued from within Claude Cowork's Linux guest environment, which is running inside an HCS-managed lightweight VM. The Linux process attempts to access a path that is mapped to the Windows host filesystem, typically something like /mnt/c/ in the WSL namespace.
That access triggers a filesystem operation in the Linux guest's kernel. The guest kernel recognizes that the path is on a 9P-mounted filesystem and passes the operation to the 9P client driver built into the Linux kernel.
The 9P client sends a protocol message across the virtio channel to the Hyper-V Plan9 server running on the Windows host side. Before any data can flow, the 9P client must first send a Tattach message to authenticate and attach to the file tree. This is the step that KB5124008 broke. The Hyper-V Plan9 server, after the September 8th update, began rejecting token-backed Tattach messages with EINVAL, so the attachment never completed.
Assuming a successful Tattach (which is what KB5129195 restores), the Plan9 server translates subsequent 9P requests into Windows file system calls, accesses the actual files on the NTFS volume, and sends responses back through the virtio channel to the Linux guest. The guest kernel delivers the data to the requesting process, and Claude Cowork sees a normal filesystem operation complete.
The entire round trip happens in milliseconds and is transparent to the user. The elegance of the design is also its vulnerability: every layer in that chain must be working correctly, and a failure at the Tattach authentication step silently blocks everything above it.
The 9P Protocol Message Flow
For readers who work at a protocol level, the 9P handshake sequence that the September 8th update disrupted looks like this under normal conditions:
| 9P Message | Direction | Purpose | Status After KB5124008 |
|---|---|---|---|
| Tversion | Client → Server | Negotiate protocol version | ✅ Still working |
| Tattach (token-backed) | Client → Server | Authenticate and attach to file tree | ❌ Rejected with EINVAL |
| Twalk | Client → Server | Navigate directory hierarchy | ⚠️ Never reached |
| Topen / Tcreate | Client → Server | Open or create files | ⚠️ Never reached |
| Tread / Twrite | Client ↔ Server | Read and write file data | ⚠️ Never reached |
| Tclunk | Client → Server | Release a file handle | ⚠️ Never reached |
The entire protocol sequence collapsed at the second step. Nothing downstream of Tattach could execute, which is why the filesystem appeared completely inaccessible from the Linux guest's perspective, even though every other aspect of the Windows system was functioning normally.
Why EINVAL Is a Particularly Opaque Error Here
EINVAL (error code 22 in POSIX systems) is a generic "invalid argument" error. It does not indicate authentication failure specifically, it does not indicate a security policy rejection, and it gives the caller no information about which argument was considered invalid or why. From the Linux guest kernel's perspective, the 9P mount simply failed with an invalid argument.
Applications built on top of that mount point, including Claude Cowork's local execution layer, see a filesystem that is either absent or unresponsive. They do not receive any message indicating that a Windows security update on the host changed a token validation rule. The error propagates upward through the stack as generic filesystem unavailability, which is why users saw Claude Cowork silently fail to execute commands rather than displaying any diagnostic information about the root cause.
This opacity is part of what made the bug difficult to diagnose quickly. The symptom (Claude Cowork not running local commands) does not obviously point to the cause (a Hyper-V Plan9 authentication change in a Windows security update). Users who had not been following the Windows Update changelog, which is most users, had no immediate reason to suspect that a system update was responsible.
WSL Got Hit the Same Way: Understanding the Shared Dependency
Windows Subsystem for Linux version 2 (WSL 2) and Claude Cowork share the same Plan9 filesystem dependency because they share the same underlying HCS virtual machine architecture. The September 8th update broke WSL 2's filesystem access for the same reason it broke Claude Cowork: both tools use token-backed Tattach requests to mount the Windows host filesystem inside their Linux guest environments.
The WSL 2 Architecture and Plan9
WSL 2, introduced by Microsoft as an upgrade from WSL 1's translation-layer approach, runs a genuine Linux kernel inside a lightweight Hyper-V VM managed by HCS. This gives WSL 2 full Linux compatibility, including the ability to run Docker containers and binary-compatible Linux applications. The cost of this approach is the dependency on Hyper-V for filesystem sharing.
When you access /mnt/c or any other Windows drive path inside a WSL 2 session, you are going through the same 9P channel that Claude Cowork uses. After the September 8th update, WSL 2 users experienced the same symptom: Windows filesystem paths became inaccessible inside WSL sessions, and any script or tool that tried to read or write to a Windows drive path failed.
The overlap in affected user populations is significant. Many developers who use Claude Cowork or Claude Code also use WSL 2 for their development environment. The simultaneous breakage of both tools from the same root cause amplified the disruption and, for technically sophisticated users, also provided the diagnostic signal: if WSL 2 and Claude Cowork broke on the same day after a Windows Update, the update was the common cause.
How WSL 1 Users Were Spared
WSL 1 uses a completely different architecture. Rather than running a real Linux kernel in a VM, WSL 1 translates Linux system calls into Windows system calls at runtime. It does not use Hyper-V, it does not use HCS, and it does not use the Plan9/9P filesystem protocol. WSL 1 accesses the Windows filesystem directly through the Windows kernel, bypassing the entire virtualization layer.
As a result, WSL 1 users were not affected by the September 8th update's Plan9 change. Their filesystem access continued working normally. This distinction is worth knowing for future reference: if a Hyper-V or Plan9 issue surfaces again, WSL 1 can serve as a diagnostic comparison point, though WSL 1 has significant limitations compared to WSL 2 and is not a practical long-term workaround for most use cases.
Docker Desktop on Windows: A Related Impact
Docker Desktop on Windows, when configured to use the WSL 2 backend (which is the default for most current installations), also passes through the HCS/Plan9 layer for volume mounts that map Windows directories into containers. Teams using Docker Desktop with WSL 2 backend and mounting Windows filesystem paths into their containers may have also experienced mount failures after the September 8th update, depending on their exact configuration.
Docker Desktop configurations that use Windows volume mounts pointing to paths inside the WSL 2 filesystem (rather than Windows filesystem paths mounted into WSL) may not have been affected, because those paths do not go through the Plan9 channel in the same way. The specific impact depends on exactly which paths and mount configurations are in use.
The Timeline: From Update to Acknowledgment to Fix
The sequence from the September 8th update to Microsoft's public acknowledgment and the release of KB5129195 moved relatively quickly by the standards of enterprise software patches. Understanding the timeline helps set expectations for how this class of problem gets resolved.
| Date | Event | Impact |
|---|---|---|
| September 8th | KB5124008 (x64) and KB5124012 (ARM64) go live | Plan9 Tattach rejection begins; Claude Cowork and WSL 2 filesystem access breaks silently |
| September 8th–11th | User reports accumulate on GitHub and community forums | Pattern emerges linking breakage to the September 8th update; EINVAL errors documented |
| September 12th | Microsoft publicly acknowledges the issue; Windows Latest reports | Affected users gain confirmation that the cause is the update, not their own configuration |
| Post-September 12th | KB5129195 released; moves systems to Build 26200.9457 or 26100.9457 | Plan9 filesystem sharing restored; Claude Cowork and WSL 2 resume normal operation |
The gap between the update going live and Microsoft's public acknowledgment was four days. For teams running production workflows through Claude Cowork, four days of broken local command execution is a meaningful disruption. The GitHub issue thread shows users working through the diagnosis in real time, with the community collectively narrowing the root cause before Microsoft's official statement arrived.
This pattern, where technically sophisticated users in public forums diagnose a system-level bug faster than official channels acknowledge it, is increasingly common as the user base for developer tools grows and community troubleshooting scales. The GitHub issue at the Anthropics Claude Code repository became the de facto diagnostic resource for this problem before any official documentation existed.
What This Incident Reveals About AI Tool Dependencies on Windows 11
The Claude Cowork / Plan9 incident is a useful case study in a class of risk that is growing as AI development tools embed deeper into the operating system infrastructure. These tools are not standalone applications that can be isolated from OS changes. They depend on virtualization layers, kernel features, and filesystem protocols that are subject to change whenever Microsoft ships a security update.
The Dependency Stack for Modern AI Development Tools
Consider what Claude Cowork actually depends on to execute local commands on a Windows 11 machine. The list is longer than most users realize:
- Hyper-V, which must be enabled and functioning correctly
- HCS (Host Compute Service), which manages the lightweight VM lifecycle
- The Plan9 / 9P filesystem server, built into the Hyper-V layer
- A compatible Linux kernel inside the guest VM, with a working 9P client driver
- Correct token-backed authentication through the Tattach mechanism
- The Windows NTFS volume being served through the Plan9 server
- Network connectivity to Anthropic's API for the conversational layer
Any one of these layers breaking, for any reason, can produce a symptom that looks like "Claude Cowork is not working" without making it obvious which layer failed. The September 8th update broke layer five (the Tattach authentication), but the symptom manifested at the application layer as silent command execution failure.
For marketing teams and non-technical users deploying Claude Cowork for content workflows, this dependency stack is largely invisible. It works, until it does not. Building a basic awareness of the virtualization dependency, specifically the fact that Claude Cowork's local execution capability runs through a Linux VM on the Windows host, gives teams a better starting point for diagnosis when problems arise.
If your team is using Claude Cowork or Claude Code for role-specific workflows, understanding the technical foundation matters more than it might initially seem. Our breakdown of Claude Code capabilities by role for marketing teams covers how different team members interact with the tool, which also helps clarify which functions are network-dependent versus locally-dependent.
Windows Update Risk and Professional Tool Deployments
The conventional advice around Windows updates has always been to apply them promptly for security reasons. The September 8th incident complicates that advice slightly, not because deferring updates is a good practice in general (it is not), but because it illustrates that security updates can break professional tools in ways that are not immediately apparent and may not be acknowledged publicly for several days.
For teams running critical workflows through AI development tools, a few practical adjustments are worth considering:
- Monitor community channels around major Windows Update releases. The GitHub issues tracker for the tools you use is a faster signal than official Microsoft documentation for this class of problem.
- Test update impacts on a non-critical machine first when a major security update ships, before rolling it out to machines running production workflows, if your organization's security posture permits that window.
- Know your OS Build number. Running
winvertakes two seconds and immediately tells you whether a known-good or known-bad build is installed. It is the fastest first diagnostic step for any OS-level tool breakage. - Document which Windows Update fixed a problem. Build numbers and KB numbers are searchable. If a future update causes a similar issue, having a record of the KB5124008/KB5129195 pattern helps you recognize the pattern faster.
The Broader Pattern: Security Hardening vs. Compatibility
Microsoft is not unique in facing this tension. Any operating system that ships security updates to a virtualization layer risks breaking tools that depend on that layer's specific behavior. The authentication validation that KB5124008 tightened was presumably tightened for a reason, even if the implementation caused unexpected breakage. KB5129195's fix restores Plan9 sharing, but it likely does so in a way that preserves the security intent while correcting the over-rejection of legitimate token-backed Tattach requests.
This pattern, security hardening that temporarily breaks compatibility, followed by a corrective update that preserves the security intent, is a standard part of the operating system update lifecycle. It is disruptive when it happens to tools you depend on, but it is also how OS security improves over time. The practical response is the same in every case: apply the fix, confirm the build number, and move forward.
Checking Your System State: A Diagnostic Framework for Windows 11 AI Tool Breakage
When Claude Cowork stops executing local commands on Windows 11, a structured diagnostic approach gets you to the root cause faster than trial-and-error. This framework applies to the current KB5124008 issue and to any future breakage in the same dependency stack.
Layer-by-Layer Diagnostic Checklist
| Diagnostic Step | How to Check | What It Tells You |
|---|---|---|
| Check OS Build number | Run winver |
Confirms whether a known-bad or known-good build is installed |
| Test WSL filesystem access | wsl ls /mnt/c/ in PowerShell |
If this fails, the Plan9 channel is broken at the OS level, not in Claude Cowork specifically |
| Check Hyper-V status | Run Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V in PowerShell |
Confirms Hyper-V is enabled and not in an error state |
| Check Windows Update history | Settings > Windows Update > Update history | Shows which KB numbers have been installed and when |
| Test Claude Cowork chat | Send a message in Claude Cowork | If chat works but commands fail, the issue is in the local execution layer (filesystem/VM), not the API connection |
| Apply KB5129195 | Settings > Windows Update > Check for updates | Resolves the Plan9 Tattach issue specifically |
| Confirm build post-patch | Run winver after restart |
Build 26200.9457 or 26100.9457 confirms the fix is applied |
The key insight in this diagnostic framework is the WSL test at step two. If wsl ls /mnt/c/ fails with a permissions error or mount failure, the problem is definitively at the OS/Hyper-V layer, not in Claude Cowork's application code. That single test eliminates a large category of potential causes and points directly to the virtualization infrastructure.
When the Fix Does Not Fully Resolve the Issue
In a small number of cases, users may find that even after installing KB5129195 and confirming the correct build number, Claude Cowork's local command execution is still not functioning. The most likely causes in that scenario are:
- A restart was not completed after the update installed. Hyper-V changes require a full restart to take effect.
- A secondary update is pending that must be installed before or alongside KB5129195. Check Windows Update for any additional pending updates after KB5129195 installs.
- The Claude Cowork application itself needs to be restarted after the OS update. Close it fully (including any background processes) and relaunch.
- A conflicting third-party virtualization tool (such as a VPN with its own virtual adapter, or a third-party hypervisor) is interfering with the Hyper-V stack after the update.
If none of these resolve the issue, the GitHub issue thread linked above is the best place to find current workarounds from other affected users, since community-sourced fixes often appear there before official documentation is updated.
For Teams Who Run Structured Claude Code Workflows
The September 8th incident is a concrete example of why structured knowledge about the tools you deploy matters. Teams that understood the HCS/Plan9 dependency were able to diagnose the issue quickly, apply the fix, and continue working. Teams that had not developed that understanding spent significantly more time in confusion before identifying the cause.
This gap in structured knowledge is something worth addressing proactively. If your team uses Claude Cowork or Claude Code as part of a regular workflow, having a shared understanding of how the tool works at the system level, not just how to use its features, reduces your exposure to exactly this kind of opaque failure. Our article on signals that indicate your team needs structured Claude Code training covers this gap in detail, including why informal self-teaching often misses the architectural knowledge that matters most when things break.
The incident also underscores that AI development tools are infrastructure, not just software. They have dependencies, they have failure modes, and they require the same kind of operational knowledge that any infrastructure tool demands. Treating them as infrastructure, rather than as magic that either works or does not, is the mindset shift that makes teams resilient when issues like this arise.
Frequently Asked Questions
What exactly is the Plan9 filesystem on Windows 11?
Plan9 refers to the 9P protocol-based filesystem sharing built into Windows 11's Hyper-V virtualization layer. It is the mechanism that allows Linux guest environments (including WSL 2 and Claude Cowork's execution environment) to access the Windows host filesystem. The name comes from Plan 9 from Bell Labs, the operating system where the 9P protocol was developed.
Which Windows 11 updates caused the Claude Cowork problem?
The updates that caused the issue were KB5124008 (for x64 systems) and KB5124012 (for ARM64 systems), both of which went live on September 8th. These security updates changed the Hyper-V Plan9/9P filesystem-sharing implementation in a way that caused token-backed Tattach requests to be rejected with an EINVAL error.
What is the fix for Claude Cowork not working on Windows 11?
The fix is Windows Update KB5129195. Go to Settings > Windows Update > Check for updates, install KB5129195, restart your machine, and confirm the build number via winver. The correct post-fix builds are 26200.9457 or 26100.9457.
Does this affect all Windows 11 users or only specific configurations?
The issue affects Windows 11 users who installed KB5124008 or KB5124012 and who use tools that depend on HCS-managed virtual machines with Plan9 filesystem sharing. This includes Claude Cowork users, WSL 2 users, and potentially Docker Desktop users with WSL 2 backend who mount Windows filesystem paths into containers.
Why did Claude Cowork chat still work but commands stopped working?
Claude Cowork's chat interface operates through a network connection to Anthropic's API, which is independent of the Plan9 filesystem channel. The Plan9 channel is only required for local command execution, where the Linux guest environment needs to access the Windows host filesystem. Because the API connection was unaffected, chat continued working while local commands failed silently.
Is WSL affected by the same issue?
Yes. WSL 2 uses the same HCS/Plan9 architecture and was affected by the same EINVAL error on token-backed Tattach requests. WSL 1 was not affected because it does not use Hyper-V or the Plan9 protocol. KB5129195 restores WSL 2 filesystem access as well as Claude Cowork's local execution capability.
How do I confirm that KB5129195 has been successfully installed?
After installing KB5129195 and restarting, run winver (press Windows key + R, type winver, press Enter). The dialog will show your OS Build number. Build 26200.9457 or 26100.9457 confirms the fix is in place. You can also verify by checking Settings > Windows Update > Update history and confirming KB5129195 appears with a successful installation status.
What is an HCS virtual machine?
HCS stands for Host Compute Service, which is Microsoft's API layer for managing lightweight virtual machines in Windows 11. HCS sits between the application layer and the Hyper-V hypervisor, allowing tools like WSL 2 and Claude Cowork to run Linux guest environments efficiently without the overhead of a full desktop VM. Claude Cowork's local execution environment runs inside an HCS-managed VM on Windows 11.
Should I stop applying Windows security updates to avoid this kind of breakage?
No. Deferring security updates creates much greater risk than the occasional compatibility issue. The correct approach is to apply updates promptly and use the community channels (GitHub issues, forums) around major update releases to quickly identify any breakage. Microsoft shipped a fix for this specific issue within days of acknowledgment.
What is a Tattach request in the 9P protocol?
In the 9P filesystem protocol, a Tattach message is the authentication and attachment handshake that a client (the Linux guest) sends to a server (the Windows host's Plan9 implementation) to attach to a specific file tree. It must succeed before any file operations can proceed. The September 8th update caused token-backed Tattach requests to be rejected, which prevented the attachment from completing and made the entire host filesystem inaccessible from the Linux guest.
Will this issue happen again with future Windows updates?
There is no way to predict whether a future update will affect the Plan9/HCS layer again. The architecture is subject to change with any Hyper-V or security update. The practical preparation is to know the dependency stack, monitor community channels around major update releases, and know how to run the diagnostic steps (winver, WSL filesystem test) that quickly identify OS-level virtualization failures.
Where can I track ongoing reports about this issue?
The primary community tracking thread is the GitHub issue at the Anthropics Claude Code repository. Windows Latest and PC Magazine have both covered the incident and the fix. Microsoft's own Windows Health Dashboard is also a useful resource for tracking known issues with current Windows builds.
Key Takeaways
- The immediate fix is KB5129195. Go to Settings > Windows Update > Check for updates, install it, restart, and confirm your build is 26200.9457 or 26100.9457 via
winver. - The root cause was Windows 11 security updates KB5124008 (x64) and KB5124012 (ARM64), shipped September 8th, which changed how Hyper-V's Plan9/9P filesystem implementation validates token-backed Tattach requests, causing them to be rejected with EINVAL.
- Claude Cowork chat still worked because the API connection is independent of the Plan9 filesystem channel. Local command execution failed because it requires the Linux guest environment to mount the Windows host filesystem through that channel.
- WSL 2 was affected identically, because it shares the same HCS/Plan9 architecture. WSL 1 was not affected.
- The diagnostic first step for any Claude Cowork local execution failure on Windows 11 is to run
winver(check the build), then test WSL filesystem access. If WSL cannot read/mnt/c/, the issue is at the OS virtualization layer. - Microsoft acknowledged the problem publicly on September 12th and has shipped KB5129195 to resolve it.
- Claude Cowork's local execution depends on a full stack: Hyper-V, HCS, the Plan9/9P server, the Linux guest kernel, and the Tattach authentication mechanism. Understanding this stack makes future diagnosis faster.
Build Fluency Before the Next Break
The teams that navigated this incident fastest were the ones who already understood how Claude Cowork sits inside the Windows virtualization stack. That kind of architectural fluency does not come from YouTube tutorials or casual experimentation. It comes from structured learning that covers not just the features of a tool but the system it runs on and the failure modes that matter in production.
AdVenture Media runs live Claude Code workshops designed for professionals who use these tools for real work, including hands-on coverage of the Windows 11 environment, the HCS architecture, and how to build workflows that are resilient to exactly the kind of OS-level change that caused this incident. If your team is running Claude Cowork or Claude Code and wants to develop that depth of understanding, the next workshop details are at adventuremedia.ai/workshops.
Join our live Claude Code workshops and training events
Learn more →
