If Claude Cowork stopped running local commands on your Windows 11 machine sometime after September 8th, you are not dealing with a corrupted install, a licensing issue, or a problem with your Anthropic account. You are dealing with the downstream effect of a security update that quietly changed how Windows shares files with Linux virtual machines, and the fix is now available. Install update KB5129195 from Settings > Windows Update > Check for updates. Once it applies, run winver and confirm your build reads 26200.9457 or 26100.9457. That is the short version.
The longer version involves a filesystem protocol called Plan9, a token-based authentication handshake called a Tattach request, a Linux error code called EINVAL, and a chain of consequences that left Claude Cowork partially functional in a way that was genuinely confusing: chat worked, basic file reading worked, but anything that required running a command against your local drive failed silently or threw cryptic errors. If you want to understand what actually happened, and why this class of bug is worth understanding for anyone who runs AI coding tools on Windows 11, keep reading.
The Fix First: How to Restore Claude Cowork on Windows 11
Microsoft has shipped a remediation update, KB5129195, that restores Plan9 filesystem sharing and unblocks Claude Cowork. The update is available through the standard Windows Update channel and does not require any manual registry edits, WSL resets, or workarounds. Here is the exact path to apply it.
Step-by-Step Update Instructions
- Open Settings (Windows key + I).
- Navigate to Windows Update.
- Click Check for updates.
- Allow the system to download and install KB5129195.
- Restart your machine when prompted.
- After restart, press Windows key + R, type
winver, and press Enter. - Confirm the build number reads 26200.9457 (for x64 systems) or 26100.9457 (for ARM64 systems).
If Windows Update shows that your system is already current and you are still on an earlier build, check whether your organization's IT policy is deferring updates, or whether a group policy is blocking the specific update rollout. In enterprise environments, that is the most common reason a known fix does not appear automatically.
How to Verify Claude Cowork Is Actually Working Again
After applying the patch, open Claude Cowork and attempt a task that requires local command execution, something like asking it to list files in a directory, run a build script, or read a file path that sits on your C: drive. If the command executes cleanly and returns output, the Plan9 mount is working. If you still see errors, note your exact OS build from winver and check whether WSL itself is functioning by opening a WSL terminal and running ls /mnt/c. A working WSL mount is a strong indicator that the underlying filesystem sharing is restored. A still-broken WSL mount means the KB5129195 update has not fully applied, or a secondary issue is present.
As PC Magazine confirmed, the KB5129195 update specifically targets the Plan9 sharing breakdown introduced by the September 8th security updates and moves affected machines to the corrected OS builds.
What KB5124008 and KB5124012 Actually Changed
The September 8th security updates modified the Hyper-V Plan9 filesystem-sharing implementation in a way that caused token-backed Tattach requests to be rejected with an EINVAL error. To understand why that matters, it helps to understand what each of those terms means in plain language, and how they connect to Claude Cowork's architecture on Windows.
The Plan9 Protocol: Windows' Bridge to Linux Filesystems
When you run a Linux environment inside Windows 11, whether through WSL2 or an HCS-managed virtual machine like the one Claude Cowork uses, the Linux guest needs a way to access files that live on the Windows host. Microsoft does not give the Linux guest direct access to the NTFS filesystem. Instead, it uses a protocol called 9P, also known as Plan9 from Bell Labs, as a network-like filesystem bridge.
Plan9 (9P) was originally developed at Bell Labs as a distributed operating system protocol in the late 1980s. It was designed to make remote resources look like local files. Microsoft adopted 9P as the mechanism for Hyper-V and WSL2 host-guest filesystem sharing because it is lightweight, well-specified, and already supported in the Linux kernel. When your WSL2 environment shows you /mnt/c, that mount is served over a 9P connection between the Linux kernel inside the virtual machine and a Plan9 server running on the Windows host.
For Claude Cowork to run commands against your local files, it relies on this exact bridge. The Linux environment inside its VM needs to mount your host drive using 9P. Without a working mount, it cannot see your files, cannot execute commands, and cannot complete tasks that require filesystem access.
What a Tattach Request Is
The 9P protocol uses a specific set of message types to manage connections and file access. A Tattach message is the authentication and attachment step, it is the handshake that establishes a connection between a client (the Linux guest) and a server (the Windows host) for a specific filesystem tree. Think of it as the guest presenting credentials and asking permission to mount a particular share.
In the updated implementation introduced by KB5124008 and KB5124012, Microsoft changed how the Plan9 server on the Windows side handles the authentication token that accompanies a Tattach request. Specifically, token-backed Tattach requests, Tattach messages that carry a security token for identity verification, began returning an EINVAL error instead of completing successfully.
What EINVAL Means and Why It Matters
EINVAL is a standard POSIX error code that stands for "Invalid Argument." In most contexts, EINVAL means the caller passed a parameter that the receiving function considers malformed, out of range, or otherwise unacceptable. It is one of the most generic error codes in Unix-like systems, which is part of what made this bug so disorienting to diagnose.
When the Linux kernel inside the VM sent a Tattach request to the Windows Plan9 server, the server rejected it with EINVAL. From the Linux side, this looked like the filesystem mount had received a bad argument, not like a permissions failure, not like a network timeout, just an invalid argument. The mount failed, the drive was not accessible, and any application relying on that mount (including Claude Cowork and WSL2) could not reach the host filesystem.
As Windows Latest reported, Microsoft publicly acknowledged that the September security updates were breaking multiple features, including virtual machine filesystem sharing, a rare and candid admission given how quickly it followed the update's release.
| Component | Role in the Chain | What the Bug Did to It |
|---|---|---|
| KB5124008 / KB5124012 | September 8th Windows 11 security update (x64 / ARM64) | Changed Plan9 Tattach token handling, introducing the EINVAL rejection |
| Plan9 / 9P server (Hyper-V) | Host-side filesystem bridge for Linux VMs | Began rejecting token-backed Tattach requests instead of completing the mount |
| HCS-managed VMs | Container for Claude Cowork's Linux environment | Could not mount host drive; lost access to local files for command execution |
| WSL2 | Windows Subsystem for Linux (also uses Plan9) | Same failure mode, /mnt/c and related mounts became inaccessible |
| Claude Cowork | AI coding assistant with local command execution | Chat and basic file viewing still worked; local command execution failed |
| KB5129195 | Microsoft's remediation update | Restores Plan9 sharing; moves systems to build 26200.9457 or 26100.9457 |
Why Claude Cowork Partially Worked, and Why That Made Diagnosis Harder
One of the most confusing aspects of this bug was that Claude Cowork did not simply stop working. It stopped working in specific, selective ways that looked like a configuration problem, a permission issue, or a bug in Claude itself, not a Windows update breaking an underlying protocol.
What Still Worked After the September 8th Update
Claude Cowork's chat interface continued to function. You could open a conversation, type messages, and receive responses. Basic file reading, where Claude reads a file you have explicitly uploaded or referenced, often still worked, because some file access paths do not require a mounted host filesystem. Lightweight file editing in certain contexts also remained available.
This partial functionality is a direct consequence of how Claude Cowork's architecture is layered. The conversational AI layer communicates with Anthropic's servers over standard HTTPS. That layer does not touch the Plan9 mount at all. The filesystem-dependent layer, the part that allows Claude to run bash commands, execute scripts, read directory trees, and interact with your project files as a working agent, is the layer that routes through the Linux VM and requires a live Plan9 mount to the host.
When the Tattach request fails and the mount does not complete, the upper conversational layer keeps working fine. The lower execution layer goes dark. From a user perspective, this looked like: "Claude responds to me, it can see files I paste in, but whenever I ask it to run something or navigate my project directory, it either fails or returns nothing."
Why This Pattern Confused Users and Support Teams
Partial failures are significantly harder to diagnose than total failures. If Claude Cowork had simply refused to open, or had displayed a clear error message saying "filesystem mount failed," the path to diagnosis would have been straightforward. Instead, users saw a tool that appeared to be working, conversations progressed, responses came back, but certain actions quietly failed.
Many users assumed the issue was with their specific project setup, their file paths, their WSL configuration, or a version mismatch between Claude Cowork and a dependency. Some users attempted to reinstall Claude Cowork entirely. Others spent time debugging WSL configurations that were, in fact, fine, the WSL environment itself was broken for the same underlying reason, but the failure surface looked different.
The GitHub issue thread for Claude Code issue #92958 shows how the diagnostic picture unfolded in real time: users comparing notes, ruling out Claude-side causes, and eventually converging on the Windows update as the common factor across affected systems. That kind of crowdsourced debugging is often how obscure infrastructure bugs get surfaced when they sit at the intersection of multiple vendor systems.
The WSL Connection: Same Root, Same Symptom
WSL2 uses exactly the same Plan9 mechanism to mount the Windows host filesystem. When KB5124008 and KB5124012 broke token-backed Tattach requests, every WSL2 instance on an affected machine lost its /mnt/c access. This meant that developers who were not using Claude Cowork at all, just running WSL2 for their own development work, hit the same wall.
The WSL failure was actually an important diagnostic signal. If your WSL2 installation also lost host filesystem access after September 8th, that was strong evidence pointing toward the Plan9 layer rather than anything specific to Claude. Conversely, if your WSL2 was working normally but Claude Cowork was still failing, it would suggest a different issue worth investigating separately. In practice, the two failures were almost always correlated, because they share the same dependency.
Plan9 Token Authentication: Why Security Updates Touch This Layer
Understanding why a security update would modify Plan9 token authentication, and why that modification had unintended consequences, requires a brief look at how HCS-managed VMs authenticate their filesystem connections and why that authentication matters from a security standpoint.
What Token-Backed Authentication Does in Plan9
In the original Plan9 protocol design, the Tattach message could include an authentication file descriptor (afid) that carries credentials. In Microsoft's Hyper-V implementation, this has been extended to support Windows security tokens, structured credential objects that carry identity and privilege information in a format Windows services understand natively.
When a Linux guest inside an HCS-managed VM sends a Tattach request to the Windows Plan9 server, it includes one of these tokens to identify itself and establish what it is authorized to access. The Windows host validates the token and, if valid, completes the mount. This token-based approach is what allows the Plan9 server to enforce access controls, ensuring that the VM can only access the parts of the host filesystem it is authorized to see, and that the connection is associated with the correct Windows user session.
Security updates that touch this layer typically aim to strengthen token validation, close edge cases where malformed tokens might bypass access controls, or align token handling with updated Windows security policies. The intent is protective. The implementation risk is that a stricter validation pass might reject tokens that were previously accepted, not because those tokens represented a security problem, but because the validation logic changed in a way that the token format did not anticipate.
Why EINVAL Is a Particularly Unhelpful Error in This Context
EINVAL signals that an argument is invalid, but it does not specify which argument, in what way, or why. In a debugging context, EINVAL from a filesystem mount operation is about as informative as a car engine that does not start and produces no error code, you know something is wrong, but the error gives you almost nothing to work with in terms of narrowing the cause.
For a developer trying to diagnose why their WSL2 mount was failing, seeing EINVAL in kernel logs would not immediately point to a token authentication issue in a Plan9 handshake. It might point to dozens of other causes: a bad mount option, an unsupported filesystem feature, a version mismatch between the 9P client and server, a corrupt mount configuration. Ruling those out systematically takes time, especially when the actual cause, a change in token validation behavior introduced by a Windows security update, is not visible from the Linux side at all.
This is a meaningful lesson about debugging at system boundaries. When a failure occurs at the interface between two operating systems, neither side's error reporting gives you the full picture. The Linux kernel reports what it received (EINVAL). It cannot report why the Windows Plan9 server sent that response. The Windows side may log more detail, but that log is not accessible from inside the Linux VM. Effective diagnosis requires looking at both sides simultaneously, which is exactly what the GitHub thread eventually did, with users comparing kernel logs, Windows event logs, and update histories to triangulate the cause.
The HCS Architecture: Why This Affects Claude Cowork Specifically
Claude Cowork's local command execution capability depends on running a Linux environment inside a Host Compute Service (HCS)-managed virtual machine on Windows. HCS is Microsoft's low-level VM management layer, and it is the same infrastructure that powers WSL2. Understanding this architecture explains both why the bug hit Claude Cowork and why the fix works at the OS level rather than requiring any changes to Claude Cowork itself.
What HCS Does and Why Claude Cowork Uses It
The Host Compute Service is a Windows API layer that allows applications to create and manage lightweight virtual machines without requiring full Hyper-V management infrastructure. WSL2 uses HCS to run the Linux kernel. Docker Desktop on Windows uses HCS for its Linux containers. Claude Cowork uses HCS to run the Linux environment where it executes commands.
This architecture makes sense for a tool like Claude Cowork. Running commands in a Linux environment provides a consistent, predictable execution context. It isolates Claude's command execution from the host Windows environment, which is both a security boundary and a compatibility benefit (Linux shell commands behave consistently regardless of what else is installed on the Windows host). And because HCS is a mature, supported Windows API, it gives Claude Cowork a reliable foundation that Microsoft maintains.
The tradeoff is that Claude Cowork's command execution capability inherits any bugs or changes in the HCS and Plan9 stack. When Microsoft changed Plan9 token authentication in KB5124008 and KB5124012, Claude Cowork had no way to compensate, the break was below its level of control, in the OS infrastructure it depends on. This is not a criticism of Claude Cowork's architecture; it is an inherent characteristic of any application that builds on OS-level virtualization primitives.
Why Chat Survived While Commands Died
Claude Cowork's architecture separates its communication with Anthropic's AI servers from its local execution environment. The conversational layer uses standard network connectivity, HTTPS to Anthropic's API endpoints, which has nothing to do with the Plan9 mount or the VM filesystem. This layer survived the KB5124008 change completely intact.
The execution layer, which sends commands to the Linux VM and reads back their output, requires the VM to have a working mount of the host filesystem. Without that mount, the execution layer cannot find project files, cannot run scripts in context, and cannot complete tasks that involve navigating or modifying the local file tree. This layer went dark when the Tattach request started failing.
The result was a tool that could talk but not act, which, for a coding assistant whose primary value is taking action on your codebase, was a significant functional regression even though it did not look like a total failure from the outside.
For teams who rely on Claude Cowork to work through complex, multi-step development tasks, this kind of partial failure can be more disruptive than a clean outage. A clean outage is immediately obvious. A partial failure can lead to hours of confused troubleshooting, incorrect assumptions about what is and is not broken, and lost productivity spread across a team before anyone identifies the root cause. If your team is still building fluency with Claude Cowork and Claude Code, understanding the tool's architectural layers, including what depends on local execution versus what runs through Anthropic's servers, is the kind of knowledge that pays off in exactly these moments. The nine signals that indicate you need structured Claude Code training include exactly this pattern: teams that can use the tool but cannot diagnose or recover from failures efficiently.
The Timeline: How This Unfolded from September 8th to the Fix
The gap between a breaking update and a confirmed fix is one of the most practically important details for anyone managing Windows 11 in a professional context. Here is the sequence of events as confirmed by verified sources.
September 8th: The Updates Ship
Windows 11 security updates KB5124008 (for x64 systems) and KB5124012 (for ARM64 systems) went live on September 8th. These were standard Patch Tuesday security updates, part of Microsoft's regular monthly update cycle. They were not flagged as high-risk at the time of release. Users and IT administrators were not warned in advance that these updates would affect Plan9 filesystem sharing or WSL2 host mounts.
Updates of this type typically apply automatically on consumer machines and are deployed through WSUS or Intune in enterprise environments. For most users, KB5124008 and KB5124012 installed overnight or on next restart, without any user-visible indication that a significant behavioral change had been made to the virtualization stack.
September 8th Onward: User Reports Begin Accumulating
Reports of Claude Cowork failures and WSL2 mount problems began appearing in GitHub issue threads, developer forums, and community Slacks shortly after the update rolled out. The initial reports were fragmented, different users describing different symptoms with different terminology, not yet converged on a common cause. Some users attributed the issue to a recent Claude Cowork update. Some assumed a WSL configuration issue. Some did not connect the timing to the Windows update at all.
The GitHub issue thread at Claude Code issue #92958 became a central gathering point for affected users. As more reports came in and users compared notes, specifically, comparing which Windows update had been applied recently, the pattern pointing to KB5124008 and KB5124012 became clear.
September 12th: Microsoft Acknowledges the Problem
Microsoft publicly acknowledged that the September update was breaking multiple features, including virtual machine filesystem sharing. This acknowledgment came four days after the update shipped, which is a relatively fast turnaround for public admission of a breaking change in a security update. The acknowledgment was reported by Windows Latest on September 12th.
The Fix: KB5129195 Ships
Microsoft released KB5129195 as the remediation update, targeting the Plan9 sharing breakdown. The update moves affected x64 systems to OS Build 26200.9457 and ARM64 systems to OS Build 26100.9457. It is available through the standard Windows Update channel and restores token-backed Tattach request handling to its pre-September-8th behavior.
What This Means If You Manage Windows 11 at Scale
For individual users, this bug is a one-time inconvenience with a clear fix. For IT administrators and engineering team leads managing Windows 11 fleets, it surfaces some structural questions about update deployment that are worth taking seriously.
The Risk of Automatic Security Update Deployment
Patch Tuesday updates are security updates, which carry an implicit message: apply these quickly, because they address known vulnerabilities. Microsoft even communicates this explicitly around major monthly updates. The September 8th updates were no exception, users were encouraged to apply them promptly.
The problem is that security updates can carry behavioral changes to infrastructure components, like Plan9 filesystem sharing, that are not always surfaced in release notes in a way that would alert administrators to test for regressions. An IT team that deploys KB5124008 and KB5124012 automatically to a fleet of developer machines, following standard security hygiene guidance, has no way to know in advance that this update will break WSL2 and Claude Cowork until the reports start coming in.
This is not an argument against applying security updates. The vulnerabilities those updates address are real. But it is an argument for maintaining the ability to roll back or ring-fence updates in environments where WSL2 or HCS-based tools are in production use, and for having a clear communication channel between affected users and IT so that update-related breakage gets surfaced and attributed quickly rather than languishing in a pile of "miscellaneous technical issues."
Testing Environments and Canary Deployment
Organizations that run developer tooling at scale, including AI coding assistants like Claude Cowork, benefit from maintaining a small cohort of machines that receive updates ahead of the broader fleet. This canary approach is standard practice in software deployment and applies equally to OS updates. If a canary machine running Claude Cowork had received KB5124008 before fleet-wide deployment, the filesystem mount failure would have surfaced in a controlled environment before affecting every developer's machine simultaneously.
This is especially relevant as AI coding tools become more central to developer workflows. When Claude Cowork is an optional convenience, a day of downtime is annoying. When it is a core part of how your team writes, tests, and ships code, a day of downtime has a measurable impact. The infrastructure reliability bar for these tools needs to match their operational importance. For teams that are embedding Claude Cowork into everyday development workflows, including the kinds of internal tool builds described in how founders are using Claude Code to build internal tools, OS-level update management becomes a genuine part of the operational picture.
Diagnosing Future Plan9 or WSL2 Issues
This incident provides a useful diagnostic template for future WSL2 or Claude Cowork failures on Windows 11. If Claude Cowork loses local command execution while chat continues to work, the first diagnostic steps should be:
- Check whether WSL2 can mount the host filesystem (
ls /mnt/cinside a WSL terminal). - Check whether a Windows update was applied recently, and if so, which one.
- Check the current OS build with
winverand compare it against known good builds. - Search the GitHub issue tracker for the specific update number plus "WSL" or "Plan9."
This sequence moves from symptoms to infrastructure to update history, which is the correct diagnostic order for a failure at the OS-virtualization boundary. It is significantly faster than attempting to debug Claude Cowork's configuration or WSL's internal setup when the actual cause is a Windows update.
The Broader Pattern: When Security Updates Break Virtualization Infrastructure
This is not the first time a Windows security update has had unintended consequences for virtualization or filesystem sharing, and it will not be the last. Understanding the pattern helps set realistic expectations for anyone running Linux workloads on Windows 11.
Why This Intersection Is Structurally Fragile
The Plan9 / 9P protocol is a relatively narrow communication channel between two very different operating systems. On one side, the Linux kernel, which has its own update cycle, its own 9P client implementation, and its own set of assumptions about how the protocol should behave. On the other side, Windows, which has its own security model, its own token authentication infrastructure, and its own implementation of the Plan9 server inside Hyper-V.
When either side changes its behavior, there is a risk of incompatibility at the boundary. Microsoft updating its Plan9 token validation logic is a Windows-side change that the Linux kernel's 9P client had no advance notice of and no ability to adapt to in real time. The result is a failure at the boundary, EINVAL, mount fails, drive inaccessible, that neither side fully "owns" in the traditional sense.
This structural fragility is a known characteristic of cross-OS virtualization, not a unique failure of Microsoft's implementation. It means that developers and teams building workflows on top of WSL2 or HCS-based tools should treat OS update testing as part of their operational practice, not an afterthought.
What Microsoft's Fast Acknowledgment Suggests
The four-day gap between the September 8th update and Microsoft's public acknowledgment of the problem is notably short for an OS vendor admitting a breaking change in a security update. Microsoft has historically been more cautious about public acknowledgment of update-related breakage, sometimes waiting for the issue to be independently confirmed across many reports before issuing official guidance.
The speed of acknowledgment in this case likely reflects the scale of the impact. When WSL2 breaks, it affects a large and vocal segment of the Windows developer community. When Claude Cowork breaks simultaneously, it amplifies the signal further. The GitHub issue thread, developer community posts, and support tickets converged quickly enough that the scope of the problem was clear within days. Microsoft's response, both in acknowledgment and in shipping KB5129195, was correspondingly prompt.
For users and administrators, the practical takeaway is that the official channels worked in this case. Checking Windows Update for KB5129195 is the correct and complete fix. There is no need for registry workarounds, manual Plan9 configuration changes, or WSL reinstallation if your system applies the remediation update successfully.
Frequently Asked Questions
What is the EINVAL error that broke Claude Cowork?
EINVAL is a standard POSIX error code meaning "Invalid Argument." In this context, it appeared when the Linux guest inside Claude Cowork's virtual machine sent a Tattach request (a filesystem connection handshake in the Plan9 protocol) to the Windows host. The September 8th security updates changed how Windows validates the security token in that request, causing the host to reject it with EINVAL instead of completing the connection. Without a successful connection, the Linux environment could not mount the host drive.
Is this a Claude Cowork bug or a Windows bug?
This is a Windows bug, specifically, an unintended behavioral change introduced by security updates KB5124008 and KB5124012. Claude Cowork did not change. Anthropic has not released a fix for Claude Cowork because no fix is needed on that side. The remediation, KB5129195, comes entirely from Microsoft and addresses the Plan9 server behavior on the Windows host.
Does this affect WSL2 as well?
Yes. WSL2 uses the same Plan9 / 9P mechanism to mount the Windows host filesystem. The same Tattach token rejection that blocked Claude Cowork also caused WSL2's /mnt/c and related mounts to fail on affected machines. Applying KB5129195 restores both Claude Cowork and WSL2 host filesystem access.
How do I know if my machine is affected?
If your machine received KB5124008 (x64) or KB5124012 (ARM64) and has not yet received KB5129195, it may be affected. Open a WSL2 terminal and run ls /mnt/c. If you see an error or empty output instead of your Windows C: drive contents, the Plan9 mount is broken. Run winver to check your current build number and compare it to 26200.9457 or 26100.9457 (the fixed builds).
What if I installed KB5129195 but Claude Cowork still does not work?
First, confirm your build number with winver. If it reads 26200.9457 or 26100.9457, the update has applied correctly. Then test WSL2 host filesystem access directly. If WSL2 can mount /mnt/c normally, the Plan9 layer is restored and any remaining Claude Cowork issue is likely a separate configuration matter. If WSL2 still cannot mount the host drive, the update may not have fully applied, try restarting the machine and running Windows Update again.
Can I roll back KB5124008 if KB5129195 has not appeared yet?
Technically, Windows allows update rollback through Settings > Windows Update > Update History > Uninstall updates. However, KB5124008 and KB5124012 are security updates, and removing them would leave your system without those security fixes. The recommended approach is to apply KB5129195 through Windows Update rather than rolling back the security patch.
Does this affect Windows 10 or only Windows 11?
The verified information for this incident relates specifically to Windows 11. The Plan9 / Hyper-V implementation used by WSL2 and HCS-managed VMs is present in Windows 10 as well, but the specific updates KB5124008 and KB5124012 are Windows 11 updates. Windows 10 users who did not receive these specific updates would not be affected by this particular incident.
Does this affect ARM64 Windows 11 machines differently?
The underlying failure is the same, token-backed Tattach requests rejected with EINVAL. The difference is the specific update KB: x64 systems received KB5124008, ARM64 systems received KB5124012. The remediation, KB5129195, targets both architectures and moves them to their respective fixed builds (26200.9457 for x64, 26100.9457 for ARM64).
Could this happen again with a future Windows update?
Any Windows update that touches the Hyper-V Plan9 server implementation, the HCS API, or Windows token authentication could theoretically introduce similar regressions. The structural risk exists because Plan9 filesystem sharing sits at the boundary between Windows security infrastructure and Linux virtualization, both of which evolve independently. Maintaining a canary machine or a small deferred-update ring in developer environments is the most practical mitigation.
Does Claude Cowork need to be reinstalled after applying the fix?
No reinstallation is needed. KB5129195 restores the underlying Plan9 sharing at the OS level. Claude Cowork's installation is not modified by the Windows update and does not need to be repaired. After applying the update and restarting, Claude Cowork should resume normal operation including local command execution.
Why did chat and basic file viewing still work if the filesystem was broken?
Claude Cowork's conversational layer communicates with Anthropic's servers over HTTPS, which is independent of the Plan9 mount. Chat responses and basic file interactions that do not require the Linux VM to access the host drive continued to function because they use a completely separate communication path. Only the local command execution layer, which routes through the Linux VM and requires a working host filesystem mount, was affected by the Plan9 failure.
Where can I follow future Windows 11 update advisories for WSL2 and Claude Cowork?
The GitHub issue tracker for Claude Code (github.com/anthropics/claude-code/issues) is the fastest-moving source for Claude-specific breakage. The Windows Release Health dashboard at microsoft.com tracks known issues with Windows updates officially. Windows Latest publishes detailed coverage of Windows update problems quickly and accurately. Following these sources gives you early warning when an update is causing widespread issues before they affect your environment.
Key Takeaways
- The fix is KB5129195. Install it via Settings > Windows Update > Check for updates. Confirm the result with
winver, your build should read 26200.9457 (x64) or 26100.9457 (ARM64). - The root cause was a Plan9 token authentication change. Windows 11 security updates KB5124008 and KB5124012, released September 8th, changed how the Hyper-V Plan9 server validates token-backed Tattach requests, causing Linux VMs to receive EINVAL when attempting to mount the host filesystem.
- Claude Cowork partially worked because its architecture has two layers. The conversational layer (HTTPS to Anthropic) continued functioning. The local command execution layer (routes through an HCS-managed Linux VM via Plan9) failed. This partial failure made diagnosis significantly harder than a clean outage would have been.
- WSL2 was hit the same way. If your WSL2 host mounts also failed after September 8th, the cause and fix are identical.
- No Claude Cowork reinstallation is needed. The fix is entirely at the OS level. Once KB5129195 applies, Claude Cowork resumes normal operation.
- The diagnostic template for future Plan9 failures: test WSL2 host mount first, check for recent Windows updates second, compare build numbers third, search GitHub issues for the specific update KB fourth.
- For teams managing Windows 11 fleets: canary rings for update deployment are the most practical mitigation for this class of breakage, especially as developer tooling built on WSL2 and HCS becomes more operationally critical.
Running Claude Cowork on Real Work: Getting Your Team to Full Capability
A bug like this one reveals something important: the teams that recovered fastest were the ones who already understood Claude Cowork's architecture well enough to reason about what was and was not broken. They tested WSL2 directly, checked their OS build, and found the GitHub thread within hours. Teams without that depth spent days troubleshooting the wrong layer.
That gap in diagnostic fluency is the same gap that separates teams using Claude Cowork as a chat tool from teams using it as a genuine force multiplier for development work. Understanding the tool's layers, what runs locally, what routes through Anthropic's servers, what depends on the underlying OS virtualization stack, is not optional knowledge for professional use. It is the foundation that makes everything else work reliably. That same architectural understanding opens up the more sophisticated use cases, like the marketing and development team workflows covered in the role-by-role breakdown of Claude Code for marketing teams.
If your team is ready to move beyond surface-level usage and build the kind of working fluency that holds up through incidents like this one, AdVenture Media runs live Claude Code workshops designed for exactly that. These are not introductory overviews, they are hands-on sessions built for professionals who are already using the tool and want to use it at a higher level. You can see the current schedule and register at adventuremedia.ai/workshops.
Join our live Claude Code workshops and training events
Learn more →
