Your Claude Cowork session stopped running local commands. WSL threw errors you hadn't seen before. You hadn't changed anything on your machine. The only thing that happened was a routine Windows Update on or around September 8th. If that's where you are right now, here's the short answer: install KB5129195. Go to Settings > Windows Update > Check for updates, let it run, then confirm your build number by pressing Win + R and typing winver. You're looking for OS Build 26200.9457 or 26100.9457. Once you see that number, the underlying problem is resolved.
That's the fix. The rest of this article explains what actually broke, why both Claude Cowork and WSL were knocked out by the same update, and what the shared kernel-level mechanism tells us about how these tools work on Windows 11. If you manage a team that runs Claude Cowork on Windows machines, understanding the root cause matters, because this kind of filesystem-sharing dependency will come up again.
What Happened: The September 8th Update and Two Tools That Stopped Working
On September 8, 2026, Microsoft pushed two security updates: KB5124008 for x64 systems and KB5124012 for ARM64 systems. Both were positioned as routine security patches, the kind that most IT administrators and individual users apply without a second thought. Within hours of deployment, reports started surfacing across GitHub and developer forums that Claude Cowork had lost the ability to execute local commands, and that WSL (Windows Subsystem for Linux) was behaving erratically or failing outright on affected machines.
The symptoms weren't identical across every user. Some people found that Claude Cowork's chat interface and basic file reading still worked. Others noticed that WSL could partially launch but couldn't access files on the Windows host drive. The inconsistency made diagnosis harder, because the surface behavior varied depending on exactly what each tool was doing at the moment it tried to cross the host-guest boundary. But underneath all of those different symptoms was a single shared failure point.
Windows Latest reported that Microsoft acknowledged the problem within days, which is relatively fast for a public admission on a security update. The acknowledgment confirmed what developers had already pieced together from error logs: the update had changed how Hyper-V handles Plan9 filesystem sharing, and that change broke the communication channel that both Claude Cowork and WSL depend on to access the host machine's drives.
For teams using Claude Cowork in production workflows, the practical impact was significant. The tool could still hold a conversation and read files that had already been loaded into its context, but any workflow that required running a command against the local filesystem, writing output back to a directory, or executing a shell script was dead in the water. That's a large percentage of the use cases that make Claude Cowork valuable in the first place, particularly for marketing teams and founders who use it to automate repetitive tasks, generate reports, or interact with local codebases.
The Technical Root Cause: Plan9, 9P, and Why This Protocol Is Central to Both Tools
Both Claude Cowork and WSL rely on a filesystem-sharing protocol called Plan9 (also known as 9P) to bridge the gap between the Windows host and the Linux guest environment running inside a virtual machine. Understanding why this protocol matters, and what the update changed about it, is the key to understanding why both tools failed simultaneously.
What Plan9 Filesystem Sharing Actually Does
When you run WSL or Claude Cowork on a Windows 11 machine, you're not running a native Linux process directly on the Windows kernel. You're running a Linux environment inside a lightweight virtual machine managed by Microsoft's Host Compute Service (HCS). That VM has its own filesystem, but for it to be useful, it needs to be able to read and write files on your Windows drives, the C:\ drive, your Documents folder, your project directories.
The mechanism that makes that cross-boundary file access possible is the Plan9 filesystem protocol, sometimes written as 9P. It's a network-style protocol, originally developed at Bell Labs, that allows one operating system to expose its filesystem to another over a local channel. In the Windows 11 context, Hyper-V acts as the broker. The Linux guest sends filesystem requests using 9P messages, and Hyper-V translates those requests into Windows filesystem operations on the host side, then returns the results to the Linux guest.
This design is elegant because it keeps the Linux guest isolated from the Windows kernel while still giving it practical access to host files. It's also the design that made KB5124008 so disruptive, because when the implementation of Plan9 sharing changes inside Hyper-V, every tool that depends on it breaks at the same moment.
What the Update Changed: Token-Backed Tattach Requests and EINVAL
The specific change that caused the failure was in how Hyper-V handled a class of 9P protocol messages called Tattach requests. In the 9P protocol, a Tattach message is how the client (the Linux guest) establishes a connection to a shared filesystem on the server (the Windows host). It's roughly analogous to mounting a network drive, but happening at the protocol level inside the virtualization stack.
KB5124008 changed the Plan9 implementation so that token-backed Tattach requests, meaning Tattach requests that include a security token as part of the authentication handshake, were rejected with an EINVAL error. EINVAL is a standard POSIX error code meaning "invalid argument." From the Linux guest's perspective, it sent a well-formed, correctly authenticated mount request and received back what amounts to a rejection with no useful explanation.
Because the mount failed, the Linux guest environment could not attach to the host drive at all. Any subsequent attempt to read or write a file on the Windows host would fail, because there was no mounted filesystem to target. The guest was effectively isolated from the host at the storage layer.
What's important to understand here is that this wasn't a bug in Claude Cowork or a bug in WSL. Both tools were sending exactly the requests they should have been sending, using an authentication mechanism that had worked correctly before the update. The change in behavior was entirely on the Hyper-V side, inside the Plan9 server implementation.
Why Chat and Basic File Reading Sometimes Still Worked
Several users noticed that Claude Cowork didn't go completely dark. The chat interface stayed responsive, and in some cases basic file reading and editing operations continued to function. This is worth explaining, because it seems counterintuitive if the mount had failed.
The explanation is that not all of Claude Cowork's operations go through the Plan9 filesystem mount. The conversational interface connects to Anthropic's API over the network, which doesn't touch the local filesystem at all. Some file operations, particularly ones involving files that had already been loaded into the tool's active context before the mount failure, could still be processed in memory. The operations that definitively required a fresh mount of the host drive, which is what happens when you ask Claude Cowork to run a shell command, write a new file to a local path, or read a file that hadn't been previously loaded, were the ones that failed with the EINVAL error propagating up through the stack.
WSL showed a similar pattern. Users who had WSL sessions already running before the update installed could sometimes continue working in those sessions for a period, because the mount had been established before the behavior changed. Fresh WSL launches after the update were far more likely to hit the failure immediately.
Why These Two Tools Share the Same Failure Mode
Claude Cowork and WSL are architecturally more similar than most users realize. Both run Linux guest environments inside HCS-managed virtual machines on Windows 11. Both depend on Hyper-V's Plan9 implementation to access the host filesystem. This shared dependency is exactly why a single change in KB5124008 knocked both tools out simultaneously.
WSL 2, which is the version most Windows 11 users run by default, operates as a lightweight Hyper-V virtual machine. Microsoft designed it this way to provide full Linux kernel compatibility, which WSL 1 couldn't offer because it translated Linux system calls directly rather than running a real Linux kernel. The trade-off was that WSL 2 introduced a virtualization boundary between Windows and Linux, and the Plan9 protocol became the bridge across that boundary.
Claude Cowork follows the same architectural pattern. To give the tool access to the local machine for running commands and reading files, it operates inside a Linux environment that is itself hosted in an HCS-managed VM. The design gives it a consistent, isolated execution environment regardless of what's on the Windows host, but it means the tool inherits the same Hyper-V dependency that WSL carries.
From a failure-mode perspective, this is an important lesson. When you have two tools that both sit on top of the same low-level infrastructure component, a change to that component creates correlated failures. The September update is a clean example of correlated failure at the virtualization layer: one policy change in how Hyper-V validates Tattach requests, and two completely different products from two completely different companies both stop working in the same way at the same time.
For marketing teams and founders using Claude Cowork as part of their daily workflow, particularly those described in our writing on how founders use Claude Code to build internal tools, this kind of dependency is worth building into your mental model of the tool. Claude Cowork's power comes from its ability to act on the local filesystem. That power flows through Hyper-V. Hyper-V is maintained by Microsoft. Changes in Windows Update can affect it.
Microsoft's Response: KB5129195 and What It Does
Microsoft issued KB5129195 as the remediation update, moving affected machines to OS Build 26200.9457 or 26100.9457. The fix restores the Plan9 sharing behavior that existed before KB5124008 changed it, specifically correcting the handling of token-backed Tattach requests so that they are accepted rather than rejected with EINVAL.
As PC Magazine reported in its coverage, the fix was delivered through the standard Windows Update channel, meaning most machines with automatic updates enabled will have received it without any manual intervention. However, depending on your organization's update policies, the timing of when your machines check for updates, or whether you're on a managed enterprise deployment with deferred update rings, you may need to trigger the check manually.
The path is straightforward: Settings > Windows Update > Check for updates. After the update installs and the machine restarts, open the Run dialog (Win + R), type winver, and press Enter. The About Windows dialog will show your OS Build number. Confirm that it reads 26200.9457 or 26100.9457. If it does, the Plan9 fix is in place and both WSL and Claude Cowork should resume normal operation.
What to Do If the Fix Doesn't Immediately Resolve Your Issue
For most users, applying KB5129195 and restarting is sufficient. But there are scenarios where the update installs correctly and the tool still doesn't behave as expected. The most common reasons are:
- The build number doesn't reflect the fix yet. Double-check with
winverthat you're actually on 26200.9457 or 26100.9457. If you're on a lower build, the update may not have fully applied. Try restarting again, or run Windows Update a second time to ensure there are no pending restart requirements blocking the final installation step. - WSL itself needs a restart. Even after the Windows Update fix is applied, WSL's virtual machine may still be running with the old (broken) mount state cached. Run
wsl --shutdownfrom a PowerShell or Command Prompt window with standard user permissions, wait a few seconds, then launch WSL again. This forces WSL to establish a fresh mount using the corrected Hyper-V behavior. - Claude Cowork's agent needs to be relaunched. Similarly, if Claude Cowork's local agent process was running before you applied the update and restarted, it may need to be fully quit and restarted rather than just reconnected. Close the application completely, verify the build number with
winver, then relaunch. - Enterprise update policies are blocking KB5129195. If your machine is managed by an organization's IT department with Windows Server Update Services (WSUS) or Microsoft Endpoint Configuration Manager, the fix may not have been approved for deployment yet. Contact your IT administrator and reference KB5129195 specifically.
If you've confirmed the correct build number and still see failures, the most useful diagnostic information is your exact OS Build number from winver and whether WSL specifically can mount the Windows filesystem. Open WSL and run ls /mnt/c/. If that command returns a directory listing of your C:\ drive, the Plan9 mount is working and the issue is elsewhere. If it returns a "no such file or directory" error or hangs, the mount is still failing despite the update, and that's worth reporting to both Microsoft and Anthropic's support channels with your build number attached.
The Anthropic GitHub issue thread at github.com/anthropics/claude-code/issues/92958 has been the central coordination point for this incident and contains useful diagnostic notes from other affected users.
What This Incident Reveals About Claude Cowork's Architecture on Windows
The KB5124008 incident is one of the clearest illustrations of where Claude Cowork sits in the Windows software stack, and why that position creates specific dependencies that don't exist on macOS or native Linux. For anyone responsible for deploying or managing Claude Cowork at scale, this is the context that matters.
The Three-Layer Model
When Claude Cowork runs on Windows 11, you're looking at at least three distinct layers of software working in sequence:
- The Windows host layer. This is your actual machine, running Windows 11, managed by the Windows NT kernel. Your files live here. Your user sessions run here. Windows Update operates at this layer.
- The Hyper-V virtualization layer. This is the hypervisor that creates and manages lightweight virtual machines. Both WSL and Claude Cowork's execution environment live inside VMs at this layer. The Plan9 filesystem server also lives here, acting as the bridge between layer 1 and layer 3.
- The Linux guest layer. This is the actual Linux environment where Claude Cowork's agent runs, executes shell commands, reads and writes files via the Plan9 mount, and interacts with your local machine. From Claude Cowork's perspective, this is the "real" environment. Everything above it is infrastructure it depends on but doesn't control.
KB5124008 changed behavior at layer 2. The effect propagated to layer 3, which is where Claude Cowork lives. Claude Cowork at layer 3 had no way to compensate for the change at layer 2, because it can't modify how Hyper-V validates Tattach requests. It could only fail gracefully for operations that required a working mount, and continue functioning for operations that didn't.
This three-layer model is also relevant for teams thinking about what Claude Cowork can and can't do on Windows. The tool's ability to take action on the local machine is real and powerful, as covered in our breakdown of Claude Code's capabilities for marketing teams, but that power flows through infrastructure that Windows Update can touch. Understanding the dependency chain helps set realistic expectations for production deployments.
The HCS (Host Compute Service) Connection
The Host Compute Service, often abbreviated HCS, is the component of Windows 11 that manages the lifecycle of Hyper-V virtual machines at the API level. When WSL creates a Linux VM, it's making HCS API calls. When Claude Cowork spins up its execution environment, it's working through the same HCS infrastructure.
HCS is also the component that owns the Plan9 server process responsible for filesystem sharing. When KB5124008 modified the Plan9 implementation, it was modifying code that runs inside HCS. Because both WSL and Claude Cowork both route their filesystem sharing through HCS's Plan9 server, both were affected by exactly the same code change at exactly the same moment.
This isn't a design flaw in Claude Cowork or WSL. Using the platform's virtualization infrastructure rather than building a parallel one from scratch is the correct architectural decision. It means less code to maintain, better security isolation, and better compatibility with Windows updates in normal circumstances. The September 8th update was an abnormal circumstance: a change that altered a specific validation behavior in a way that broke existing clients without a migration path.
The Broader Pattern: When Security Updates Break Developer Tools
The KB5124008 incident fits a recognizable pattern in how security updates interact with developer infrastructure on Windows. Security patches that touch the virtualization stack carry higher risk than patches that address vulnerabilities in user-space components, because the virtualization stack is shared infrastructure for a wide range of tools.
When Microsoft tightens security in a component like the Plan9 server, the intent is typically to close an attack surface. Token-backed Tattach requests are a potential vector if not handled correctly, and it's plausible that the change in KB5124008 was intended to harden that validation. The problem is that tightening validation in a shared protocol implementation can reject not just malicious requests but also legitimate ones that were previously accepted under a more permissive policy.
This is a known tension in security engineering: stricter validation reduces attack surface but also increases the chance of breaking existing behavior that clients depended on. The Plan9 incident is a textbook case where a security tightening change broke a behavioral contract that existing clients (WSL, Claude Cowork, and potentially other tools) relied on without those clients being updated simultaneously to accommodate the new validation logic.
For teams that manage Windows machines and depend on tools like Claude Cowork in daily workflows, the practical lesson isn't to stop applying security updates. That would create far larger risks than the occasional compatibility issue. The lesson is to maintain awareness of which of your tools depend on virtualization infrastructure, and to have a test process that catches regressions in those tools quickly after a major update cycle.
A simple test: after any Windows Update that touches system components, open WSL and run a basic mount check (ls /mnt/c/). If that works, the Plan9 layer is healthy and Claude Cowork's filesystem operations will work. If it doesn't, you know to investigate before your team runs into failures mid-workflow.
Impact Assessment: What Broke, What Didn't, and Why It Matters for Teams
Not every Claude Cowork capability was affected equally by the Plan9 failure, and understanding the breakdown helps teams assess their exposure and prioritize testing after applying KB5129195.
| Claude Cowork Capability | Affected by KB5124008? | Why |
|---|---|---|
| Chat and conversational interface | ❌ Not affected | Routes to Anthropic's API over the network; no local filesystem access required |
| Reading files already in context | ⚠️ Partially affected | Files already loaded into memory before mount failure could still be processed; new reads from the host drive failed |
| Reading new files from Windows host | ✅ Affected | Requires an active Plan9 mount; Tattach rejection blocked new host file access |
| Writing files to Windows host | ✅ Affected | Write operations require the Plan9 mount; failed with EINVAL propagating up |
| Running shell commands (bash, PowerShell via Linux) | ✅ Affected | Command execution that touches host paths requires the mount; commands operating purely within the Linux guest's own filesystem were less affected |
| WSL terminal sessions (existing, pre-update) | ⚠️ Partially affected | Sessions with mounts established before the update often continued working until the next WSL restart |
| WSL fresh launches after update | ✅ Affected | New Tattach requests rejected immediately on launch; /mnt/c and other host mounts unavailable |
For teams where Claude Cowork is used primarily for conversational tasks or document drafting that doesn't involve local file operations, the impact of this incident was minimal. For teams using Claude Cowork in agentic workflows that write output to local directories, execute scripts, or pull data from local files, the impact was severe and immediate. Those are the workflows that teams should prioritize testing after applying KB5129195 to confirm full restoration of function.
Enterprise and Managed Device Considerations
Organizations running Windows 11 through enterprise management platforms face a more complex remediation path than individual users. The standard advice of "go to Settings > Windows Update and check for updates" assumes the machine receives updates directly from Microsoft's servers. Enterprise machines frequently don't.
Common enterprise configurations that affect update delivery include Windows Server Update Services (WSUS), Microsoft Endpoint Configuration Manager (MECM, formerly SCCM), Microsoft Intune with update rings, and group policy settings that defer feature or quality updates by a fixed number of days. In any of these configurations, KB5129195 may not be available to affected machines until the IT or security team explicitly approves it for deployment.
If you're in an enterprise environment and your machines are still on a pre-fix build, the right path is to contact your IT administrator with the specific KB number (KB5129195) and the target build numbers (26200.9457 or 26100.9457). Most enterprise IT teams can expedite approval for a specific patch when there's a documented business impact, and "Claude Cowork is unable to run local commands for our marketing and content teams" is a concrete, documentable business impact.
It's also worth noting that enterprise environments that use the deferred update ring model may have avoided the initial KB5124008 deployment entirely if their deferral period extended past the point when KB5129195 was issued. In that case, those machines may receive the fix as part of the cumulative update that supersedes KB5124008, without ever having been in the broken state. Check your build number with winver to confirm where your machines actually stand before investing time in remediation.
What WSL Users Need to Know Specifically
WSL users who aren't running Claude Cowork still need to apply KB5129195 if they were affected by the September 8th update. The Plan9 failure is a platform-level issue, not a Claude Cowork issue, and it affects any WSL 2 workflow that accesses the Windows host filesystem.
Common WSL workflows affected by the Plan9 failure include:
- Development environments that store code on the Windows filesystem and build or test it from within WSL (a very common pattern for web developers on Windows)
- Data science workflows that pull datasets from Windows directories into Linux-based tools like Python, R, or Julia
- DevOps tooling that uses WSL to run shell scripts that interact with Windows-hosted configuration files or deployment artifacts
- Any workflow using Docker Desktop on Windows with the WSL 2 backend, since Docker Desktop uses WSL 2 as its Linux layer and its volume mounts go through the same Plan9 mechanism
The Docker Desktop case is particularly worth flagging. Teams that don't use Claude Cowork at all but do use Docker Desktop on Windows 11 may have experienced container volume mount failures after KB5124008, for exactly the same reason: Docker Desktop's WSL 2 backend depends on Plan9 filesystem sharing to mount Windows directories as Docker volumes. The fix is the same, KB5129195, and the verification path is the same (winver confirming the target build number).
After applying the fix, WSL users should run wsl --shutdown and then relaunch WSL rather than simply continuing an existing session. This ensures WSL establishes a fresh Plan9 mount using the corrected Hyper-V behavior, rather than potentially inheriting any cached state from the broken period.
Timeline of the Incident
Having a clear timeline helps teams assess whether their machines were affected and for how long. Based on the verified facts of this incident:
| Date | Event |
|---|---|
| September 8, 2026 | Microsoft releases KB5124008 (x64) and KB5124012 (ARM64). The updates change Plan9/9P Tattach validation in Hyper-V, causing token-backed mount requests to be rejected with EINVAL. Claude Cowork loses local command execution. WSL 2 filesystem access to the Windows host fails on fresh mounts. |
| September 12, 2026 | Microsoft publicly acknowledges the problem. Developer and IT communities have already identified the Plan9 connection through error log analysis. Reports consolidated on GitHub and developer forums. |
| Post-September 12, 2026 | Microsoft releases KB5129195. Affected machines update to OS Build 26200.9457 or 26100.9457. Plan9 sharing behavior is restored. Claude Cowork and WSL resume normal filesystem operations. |
The window of impact for machines with automatic updates enabled was approximately four days between the breaking update and the fix being publicly acknowledged, with the actual fix shipping sometime after Microsoft's acknowledgment. Machines that applied automatic updates promptly on September 8th were exposed to the broken behavior for that entire period unless users identified the issue independently and applied a workaround.
Why This Is Documented So Thoroughly in the Anthropic GitHub Thread
The GitHub issue thread at github.com/anthropics/claude-code/issues/92958 became one of the more detailed public post-mortems of this incident. It's worth spending a few minutes reading through if you want to understand the full scope of how the failure manifested across different machine configurations and workflow types.
What the thread illustrates clearly is that the developer community identified the Plan9 root cause remarkably quickly. Within hours of the first reports, users were pulling error logs from the Linux guest environment and recognizing the EINVAL pattern. The 9P protocol is well-documented and the error codes are unambiguous once you know what to look for. The connection between WSL and Claude Cowork failures was noted in the thread early, which helped confirm that the issue was at the Hyper-V layer rather than in either tool's own code.
The thread also illustrates the value of centralized issue tracking for incidents like this. Individual users who only knew that Claude Cowork had stopped working could find the thread, confirm their symptoms matched, and get accurate diagnostic guidance without having to reverse-engineer the cause themselves. For teams deploying Claude Cowork at scale, following Anthropic's GitHub repository is a practical early-warning system for issues like this.
Frequently Asked Questions
What is KB5124008 and why did it break Claude Cowork?
KB5124008 is a Windows 11 security update for x64 systems that went live on September 8, 2026. It changed how Hyper-V handles Plan9 filesystem sharing by rejecting token-backed Tattach requests with an EINVAL error. Because Claude Cowork runs inside a Linux virtual machine that depends on Plan9 to access the Windows host filesystem, the rejection of those mount requests prevented Claude Cowork from executing local commands or reading and writing files on the host drive.
Is KB5124012 the same issue for ARM64 users?
Yes. KB5124012 is the ARM64 equivalent of KB5124008 and contained the same change to the Plan9 implementation. ARM64 Windows 11 users on machines like the Snapdragon X Elite-based laptops experienced the same Claude Cowork and WSL failures. KB5129195 addresses both the x64 and ARM64 variants.
How do I confirm the fix has been applied to my machine?
Press Win + R, type winver, and press Enter. The About Windows dialog shows your OS Build number. The fix is in place if your build reads 26200.9457 or 26100.9457. If you see a lower build number, go to Settings > Windows Update > Check for updates and apply any available updates, then restart and check again.
Will Claude Cowork automatically recover after KB5129195 is installed, or does it need to be restarted?
You should fully quit and relaunch Claude Cowork after applying the update and restarting your machine. The underlying Plan9 mount needs to be re-established using the corrected Hyper-V behavior, and that happens when the tool's Linux environment starts fresh. Simply reconnecting to an existing session may not be sufficient.
Does this affect Claude Cowork on macOS or Linux?
No. This issue is specific to Windows 11 and the Hyper-V Plan9 implementation. Claude Cowork on macOS uses a different virtualization stack and filesystem sharing mechanism. Native Linux installations don't use Hyper-V at all. The failure is entirely contained to Windows 11 machines that received KB5124008 or KB5124012.
My WSL is fixed after applying KB5129195, but Claude Cowork still isn't working. What should I do?
First, confirm your OS Build number with winver matches 26200.9457 or 26100.9457. Then fully quit Claude Cowork, run wsl --shutdown from a PowerShell window, wait a few seconds, and relaunch Claude Cowork. If WSL's filesystem access is working (test with ls /mnt/c/ in a WSL terminal) but Claude Cowork still can't run local commands, the issue is likely in Claude Cowork's own process state rather than the platform. Contact Anthropic support with your build number and a description of which operations are failing.
Could this happen again with future Windows Updates?
It's possible. Any Windows Update that touches Hyper-V's Plan9 implementation or the Host Compute Service could potentially affect Claude Cowork and WSL. The practical mitigation is to test WSL filesystem access after major updates (ls /mnt/c/ in a WSL terminal is a fast check) before relying on Claude Cowork for production workflows. Monitoring Anthropic's GitHub issues and Microsoft's Windows release health page provides early warning when an update causes widespread issues.
Does Docker Desktop on Windows have the same issue?
Yes, if Docker Desktop is configured to use the WSL 2 backend (which is the default on Windows 11). Docker Desktop's container volume mounts that reference Windows directories go through the same Plan9 mechanism. Affected machines would have seen volume mount failures for Windows-hosted directories. KB5129195 resolves this as well.
Where can I find the official Anthropic discussion thread about this issue?
The central tracking issue is on Anthropic's GitHub repository at github.com/anthropics/claude-code/issues/92958. It contains error logs, diagnostic steps, and confirmation of the Plan9 root cause from affected users.
Should I delay applying Windows Updates in the future to avoid issues like this?
Delaying security updates creates risks that outweigh the occasional compatibility issue. The better approach is to apply updates promptly and have a fast test for your most critical tool dependencies. For Claude Cowork and WSL, that test is a simple WSL filesystem check that takes about ten seconds. If it fails after an update, you can report the issue and look for a fix rather than having delayed the security patch entirely.
Was this a Claude Cowork bug or a Windows bug?
The root cause was in Windows 11's update (KB5124008), specifically in how the Hyper-V Plan9 server changed its validation of Tattach requests. Claude Cowork was sending correctly-formed requests that had worked before the update. The rejection originated in Microsoft's code, not in Claude Cowork's. Microsoft acknowledged this and issued KB5129195 as the fix.
How does this incident affect teams considering adopting Claude Cowork on Windows?
It's a realistic data point, not a reason to avoid the tool. Claude Cowork's local filesystem capabilities are genuinely powerful, and the architectural choice to use Hyper-V and Plan9 is the correct one for the level of isolation and compatibility the tool needs. Incidents like this are rare and were resolved within days. The practical response is to include a post-update WSL filesystem test in your team's standard operating procedure, not to avoid a tool that otherwise works well.
Key Takeaways
- Apply KB5129195 now if you haven't already. Settings > Windows Update > Check for updates. Confirm build 26200.9457 or 26100.9457 with
winver. - Both Claude Cowork and WSL failed for the same reason: they both depend on Hyper-V's Plan9 filesystem sharing, and KB5124008 changed Plan9 Tattach validation in a way that rejected legitimate mount requests with an EINVAL error.
- Chat and basic in-context operations weren't affected. The failure was specifically in operations that required a live Plan9 mount to the Windows host filesystem, including local command execution, new file reads, and file writes.
- After applying the fix, restart cleanly. Run
wsl --shutdownbefore relaunching WSL or Claude Cowork to ensure a fresh mount is established using the corrected behavior. - Enterprise environments may need IT administrator action to approve and deploy KB5129195 if machines are managed through WSUS, MECM, or Intune update rings.
- Docker Desktop on Windows with the WSL 2 backend was affected by the same Plan9 failure and is resolved by the same update.
- A 10-second test (
ls /mnt/c/in a WSL terminal) can tell you whether the Plan9 layer is healthy after any future Windows Update that touches system components. - The root cause was in Microsoft's update, not in Claude Cowork or WSL. Both tools were behaving correctly. The fix came from Microsoft, not Anthropic.
Get More from Claude Cowork with Hands-On Training
Understanding how Claude Cowork sits in the Windows stack, what it can access, what it can't, and how to recover when something at the platform level changes, is the kind of knowledge that separates teams who use the tool effectively from teams who use it tentatively. If your team is still figuring out how to integrate Claude Cowork and Claude Code into real workflows, whether that's for building internal tools, running marketing operations, or moving past YouTube tutorials into structured, production-ready usage, the right environment makes a significant difference.
AdVenture Media runs live Claude Code workshops designed for professionals who want to build real competency, not just surface familiarity. If you want to learn in a structured setting with hands-on guidance, browse upcoming workshops and events at adventuremedia.ai/workshops.
Join our live Claude Code workshops and training events
Learn more →
