Claude Cowork "Plan9 mount failed" on Windows: how to fix it

Fix it

These steps fix the current error, Plan9 mount failed: invalid argument. A Windows update released on September 8, 2026 caused it. If your error ends in bad address instead, see the older error.

1. Find your Windows version and build. Press the Windows key and R together, type winver and press Enter. The window shows your version (such as 25H2) and an OS Build number (such as 26200.9457).
2. Install the latest Windows update, then restart your PC. On Windows 11, open Settings › Windows Update. On Windows 10, open Settings › Update & Security › Windows Update. Select Check for updates and install what it offers. This is Anthropic's fix: "Install the latest Windows update and restart your PC." The table below lists the fix update for each version. If Windows Update doesn't offer your fix update, search for its KB number in the Microsoft Update Catalog.
3. Leave Claude as it is. Anthropic's changelog says "No Claude Desktop update is needed." Restarting or reinstalling Claude doesn't help, because the cause is in Windows.
4. Check it worked.
   • Run winver again. Your build should match the table, or be higher. On a 26300 build (Release Preview or 26H2), see Insider builds instead.
   • Ask Cowork to run a simple command, such as echo hello. It should run without a "no Plan9 drive shares mounted" message.
   • Reading or saving a file isn't a test: users report those kept working while commands failed.
   • One user suggests giving the workspace a couple of minutes to start the first time.

Anthropic's changelog names KB5129195, KB5129242 and KB5129236. Microsoft's release-health pages name the update that caused the issue and the update that fixed it, and Microsoft's update pages give the builds. Those pages say the issue is resolved in each fix update "and in updates released after this date" (September 14, 2026), so a later update fixes it too. One user each confirmed a later update: KB5127648 (October) on Windows 11, and KB5126657 on Windows 10.

If you install KB5129195 by hand from the Microsoft Update Catalog, Microsoft says to install the checkpoint update KB5043080 first.

Status:

• Fixed by Microsoft on September 14, 2026. Anthropic's changelog and status page say that day's Windows update fixes Cowork. Microsoft's known-issue entry names Claude Cowork as one of the affected apps, and marks the issue resolved.
• Users confirm the fix: 5 users confirm the fix and give build 26200.9457. 3 more say it worked without giving a build, one of them only after also reinstalling Claude Desktop. 3 Windows 10 users confirm KB5129236.
• Fixed by Microsoft, no user confirmation yet: Windows 11 26H1, Windows 11 23H2 and Windows 10 21H2 / LTSC 2021.
• Not fixed, per users: Windows Server and one Insider build. See Still failing?
• On GitHub, the two main issues (#92984 and #92958) were still open on November 6, 2026, with no reply from Anthropic.
• How this page was made: Kingy didn't reproduce this Windows-only error. This page is Sourced: it comes from Anthropic's changelog, status page and help articles, Microsoft's update and release-health pages, and user reports that name versions.

What you see

Anthropic's changelog says that in Cowork, "tasks fail or the workspace does not start". Its status page said Cowork was "unable to run local commands", because its workspace could no longer reach your drive.

Messages users report:

• In the app (users quoting it):
  • "A Windows update released September 8 prevents Claude's workspace from reaching your files."
  • "Claude couldn't connect your C: drive to its workspace". 3 users saw this, from app 1.52386.0.0 (September 11).
  • Later app versions end the message with "Install the latest Windows update and restart your computer." 2 users saw this.
• When Cowork runs any command, even echo:
  • sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
  • ... is under Plan9 share "c" which is not mounted (the share name varies)
• At start-up or in the app log: RPC error -1: host drive share "c" not mounted: Plan9 mount failed: invalid argument
• In the workspace log, one line per drive: failed to mount Plan9 share "c": Plan9 mount failed: invalid argument, then [hyperv] mounted 0/9 Plan9 shares. Newer app versions log errno=22 (app log) or Rlerror ecode=22 (invalid argument) (workspace log) instead.
• After downloading the workspace again, users report seeing RPC error -1: SDK version 2.1.260 not verified instead.

Microsoft's description matches: apps "might display an error indicating that no Plan9 drive shares were mounted".

Users found these lines in three log files:

• C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log (the workspace)
• C:\ProgramData\Claude\Logs\cowork-service.log (the Windows service)
• %LOCALAPPDATA%\Claude\Logs\cowork_vm_node.log (the app)

What still works: Anthropic says "Cloud sessions and Claude Code, including the Code tab, are not affected." Its status page said "chat and file reading and editing still work" for most users, and users report the same: only commands failed.

On a company deployment? Anthropic's changelog says Cowork on third-party inference deployments was affected too. So were Chat sessions on those deployments that use advanced file analysis.

Why it happened

When a Cowork session runs on your PC rather than in the cloud, its shell commands and code run inside a Linux virtual machine (VM). On Windows that VM uses Hyper-V. Reading and writing files happens outside the VM, which is why that kept working (Anthropic's architecture overview). Windows shares your drives with the VM using a method called Plan9. Anthropic says Cowork sessions now run in the cloud by default; this error affects sessions that run on your PC.

The Windows update released on September 8, 2026 broke that sharing. The virtual machine still starts, but Microsoft says the shared folders "do not appear or cannot be accessed in the guest". So the workspace can't reach your files, and Cowork's commands fail. Microsoft says Claude Cowork and WSL are "two of the applications affected".

Anthropic's changelog: "The cause is a change in Windows, so restarting or reinstalling Claude does not help."

Timeline:

• September 8, 2026: Windows update released (KB5124008 on Windows 11 24H2 and 25H2).
• September 9: the two main GitHub issues are opened.
• September 10: Anthropic posts a known issue and a status-page incident. App 1.52386.0 starts naming the Windows cause instead of deleting and reinstalling the workspace. Anthropic says this doesn't fix the problem.
• September 11: Microsoft opens a known issue.
• September 14: Microsoft releases the fix updates. Anthropic and Microsoft mark the issue resolved.

The Claude app version wasn't the cause. 10 or more users kept the app at 1.49585.0 while removing or reinstalling the Windows update. Cowork broke or worked along with the Windows update each time. Users saw the error on app versions from 1.46388.4 to 4.4212.0.0.

Affected versions (Microsoft): Windows 11 26H1, 25H2, 24H2 and 23H2, and Windows 10 22H2 and 21H2. For Windows Server, Microsoft lists "None", but users report otherwise (see below). Users reported the error on Home, Pro, Enterprise, Home Single Language and IoT LTSC editions.

Still failing after the update?

First, run winver again and compare your build with the table. One user notes that Windows Update's history can still list an update you removed, so check the build number instead (they used cmd /c ver; winver shows the same build).

Then see whether one of these cases fits.

Windows Server 2025 or 2022.

• Microsoft's affected list says "Server: None".
• But 2 users on Server 2025 still saw the error after Microsoft's September 14 out-of-band update KB5129235 (26100.33451). On Server 2022, 1 user still saw it after KB5129237, and another saw it on the September update KB5122882.
• We found no Anthropic page that says whether Cowork supports Windows Server.
• One Server 2025 user got Cowork working by removing both September updates (back to build 26100.33296). That also removes their security fixes. We don't recommend this.

Windows Insider builds.

• 3 users report Release Preview build 26300.9539 still failing, or failing on and off.
• One user said 26300.9550 worked on a first test (September 23, 2026).
• On the Beta channel, one user reports build 26220.9492 fixed it.

Windows 11 26H1 on ARM64.

• Microsoft names KB5124012 (build 28000.2954) as the update that caused the issue, and users report it broke Cowork.
• Microsoft says KB5129194 (build 28000.2956) fixes it.
• Anthropic's changelog doesn't mention 26H1, and no user has confirmed it fixes Cowork yet.

Windows 11 23H2. Anthropic and Microsoft name KB5129242 (build 22631.7584) as the fix. We found no user reports of the error or the fix on 23H2.

Windows 10 21H2 or LTSC 2021 (build 19044).

• Anthropic, and Microsoft's release-health page for Windows 10 Enterprise LTSC 2021, say KB5129236 fixes it.
• Microsoft's KB5129236 article lists the Plan9 fix only under 22H2.
• We found one user report of the error on build 19044 (September 27, 2026), and no report of the fix working there.

Only one extra drive fails, such as Google Drive.

• Users report Plan9 mount failed: file exists (3 users) or permission denied (2 users) on an extra drive letter, while C: works.
• One user with KB5129195 installed saw a Google Drive folder fail to mount, while Cowork's commands still ran.
• This may be a separate issue, and we found no fix.

The app blames the September update, but your build is already fixed. One Windows 10 user past the fix still saw that message. The real cause was a different folder problem, with SDK version 2.1.309 not verified in the log (app 4.4212.0.0, October 29, 2026). If your build is current, check the logs for a different error.

Still nothing? One user says it worked only after also reinstalling Claude Desktop, after the Windows fix. That's a single report, and Anthropic says no Claude update is needed.

For IT admins: Microsoft says IT admins who deployed a temporary mitigation through Group Policy "must re-enable the Group Policy", then install the out-of-band update and restart. Microsoft's page doesn't name the policy.

Stopgaps, if you can't update yet

The Windows update is the real fix. These only work around the problem.

• Run the task as a cloud session. Anthropic says cloud sessions aren't affected.
• Use Claude Code or the Code tab. Anthropic says those aren't affected either.
• Use Cowork for file work only. Anthropic's status page said file reading and editing still worked for most users, and users report the same. One user reports that file changes seemed to revert while the drive share was down, so check your files.

Removing the September update: don't (obsolete).

Before the fix existed, users got Cowork back by uninstalling the September update. More than 30 Windows 11 users said removing KB5124008 worked, and one Windows 10 user said removing KB5122878 worked. Don't do this now. Install the fix update instead. Users reported real risks:

• It removes that month's security fixes.
• On about 10 machines, the update couldn't be removed (errors 0x800f0825, 0x800f0926 and 0x800f0905).
• One machine wouldn't start afterwards (error 0xc0000428). Another got stuck in a crash loop after the update was removed with DISM. These are single reports.
• One user says Windows Update put the update back within minutes.

If you removed it earlier: 3 users installed KB5129195 straight onto a machine where they had removed the September update, and it fixed Cowork. One more went straight to the October update KB5127648.

What users say did not help:

• Restarting the app or the PC, or starting a new session. Anthropic also says restarting or reinstalling won't help.
• Reinstalling or repairing Claude Desktop, or downloading the workspace again.
• The Help › Troubleshooting options. One user's "Delete VM Bundle and Restart" cleared only a separate error, about a user that "already exists", and the drive still failed to mount. Another user's "Delete Cowork VM Sessions and Restart" failed with an error.
• Turning on Windows Hypervisor Platform. One user also turned Hyper-V and Virtual Machine Platform off and on again, with no change. Anthropic says Cowork needs Virtual Machine Platform in general, so leave it on.
• WSL. The error happened with WSL installed, updated or not installed at all.
• Moving your folder. Local disk, OneDrive, Dropbox, Google Drive and paths without spaces all failed together.
• Pausing antivirus (ESET, AhnLab V3), or turning off Defender's Controlled Folder Access.

Avoid "Reset Application Data". One user reports it deleted their local Cowork data, and the error stayed.

Older error: "Plan9 mount failed: bad address" (February to March 2026)

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

This was a different, older problem, not the September Windows update.

• Who saw it: about 57 users, from February 18, 2026, on Claude Desktop 1.1.x versions. Users described Cowork working at first, then failing after the first session, after 30 to 50 minutes idle, or after about an hour of use.
• What Anthropic said: on March 10, 2026, an Anthropic developer (going by their GitHub profile) wrote "we believe this is fixed in 1.1.5749". No user in that issue confirmed the fix. 2 users still saw the error on March 15 and 18, without naming a version. The last report we found was on June 1, 2026, on the older app 1.1.4498.
• Cause: Anthropic hasn't published one. Earlier, an Anthropic developer called it a "possible resource or handle leak".
• What to do: update Claude Desktop. The current version is v4.23118.0 (November 5, 2026), well past 1.1.5749.
• Workarounds users reported back then, none naming an app version:
  • End every claude.exe in Task Manager's Details tab, reopen Claude, then sign out and back in (4 users).
  • Restart the CoworkVMService service (3 users).
  • Users said rebooting helped only for a while.
  • We don't recommend the unofficial fix scripts posted in that thread.

Related error: "Virtualization is not enabled"

The full message says "Claude's workspace requires hardware virtualization (Hyper-V)." It tells you to turn virtualization on in BIOS/UEFI.

• February 2026: users report Claude Desktop 1.1.3918 showed it on PCs with virtualization fully on. On February 21, 2026, an account named JacquesAnthropic, which has triage rights on Anthropic's repository (it assigned and closed the issue), wrote "we just pushed a new version", v1.1.3963. 4 users confirmed that version fixed it.
• On a newer version: one user still saw it on 1.1.6452 (March 13, 2026). Another found virtualization really was off in their BIOS. These are single reports.
• Anthropic's Windows deploy guide says Cowork requires the Virtual Machine Platform feature. For a related error, "Missing HCS services", the guide says:
  • Turn the feature on with Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All (Anthropic's guide). Run it in PowerShell opened with Run as administrator: Microsoft's WSL setup guide says to do that when turning this feature on.
  • Then choose Restart, not Shut down. Fast Startup can leave virtualization services uninitialized.
  • If VMware or VirtualBox is installed, check from an administrator prompt that bcdedit shows hypervisorlaunchtype Auto.
  • Virtual machines or VDI without nested virtualization aren't supported.

Sources

Anthropic: read 2026-11-06.

• Claude Desktop changelog: "Known issue: Cowork on Windows" (2026-09-10), v1.52386.0 (2026-09-10) and "Resolved: Cowork on Windows" (2026-09-14). The newest entry is v4.23118.0 (2026-11-05).
• Claude status: Degraded functionality for Claude Cowork on Windows. Identified 2026-09-10, resolved 2026-09-14. Says chat and file reading and editing still worked for most users.
• Claude Cowork architecture overview: sessions run in the cloud by default; in sessions on your PC, only shell commands and code run in a Linux VM (Hyper-V on Windows).
• Deploy Claude Desktop for Windows: the Virtual Machine Platform requirement and the "Missing HCS services" steps.

Anthropic developers on GitHub (MarshallOfSound by their profile, "Building @ Anthropic"; JacquesAnthropic by account name and triage actions. GitHub doesn't mark either as staff.):

• #26554 comment (2026-03-10): "bad address" believed fixed in 1.1.5749.
• #27576 comment (2026-02-24): "possible resource or handle leak".
• #27316 comment (2026-02-21): v1.1.3963 for "Virtualization is not enabled".

Microsoft: read 2026-11-06.

• KB5124008: known issue "Host folder shares might be unavailable in Hyper-V-based Linux VMs", marked resolved.
• KB5129195 (2026-09-14): builds 26200.9457 and 26100.9457, and the KB5043080 checkpoint note.
• KB5129236 (2026-09-14): builds 19045.7727 and 19044.7727. The Plan9 fix is listed only under 22H2.
• KB5129194: build 28000.2956, with the Hyper-V Plan9 fix.
• KB5129242: build 22631.7584, with the Hyper-V Plan9 fix.
• Windows 11 25H2 resolved issues: opened 2026-09-11, resolved 2026-09-14 by KB5129195 "and in updates released after this date". Names Claude Cowork and WSL, lists the affected versions, and has the Group Policy note.
• Windows 11 26H1 resolved issues: caused by KB5124012 (28000.2954), resolved by KB5129194.
• Windows 11 23H2 resolved issues: caused by KB5122880, resolved by KB5129242.
• Windows 10 22H2 resolved issues: caused by KB5122878 (19045.7725), resolved by KB5129236.
• Windows 10 Enterprise LTSC 2021 (21H2) resolved issues: caused by KB5122878 (19044.7725), resolved by KB5129236.
• Microsoft's WSL setup guide, step 3: open PowerShell as Administrator to turn on Virtual Machine Platform.

GitHub user reports in anthropics/claude-code, read 2026-11-06:

• #92984 and #92958: the main September reports. Error text, log files, affected builds, fix confirmations, removing the update, and what didn't help.
• #92977: a KB5129195 confirmation.
• #93682, #94868 and #94869: in-app messages and Insider builds.
• #93071 and #93358: Windows 10, Windows 10 21H2 and Server 2022.
• #95910: Insider Release Preview.
• #99420: Windows Server 2025.
• #95557, #65936, #77005 and #66535: extra drive letters, including Google Drive.
• #105511: the message blaming the September update on an already-fixed PC.
• #26554, #27576, #28890, #30164 and #64444: the older "bad address" error.
• #27316: "Virtualization is not enabled".