The practical message is straightforward: Windows 11 24H2 and 25H2 users affected by Claude Cowork local-command failures, WSL-related host-folder access problems, or Remote Desktop instability should look for KB5129195. The update raises the operating-system build to 26100.9457 on 24H2 and 26200.9457 on 25H2. It is available through Windows Update and, according to Microsoft, installs automatically unless an organisation’s update policies control deployment.
That does not mean every reported problem after the September update has been solved. Most notably, the emergency release fixes only a narrow multichannel USB Audio Class 1.0 issue. Other listed USB audio failures remain unresolved. Claims of an AMD Radeon-specific regression are also not confirmed by Microsoft or AMD in the material available.
What KB5124008 changed—and what it broke
KB5124008 was the September 8, 2026 Windows 11 security update for versions 24H2 and 25H2. It moved those releases to builds 26100.9445 and 26200.9445 respectively.
After its deployment, Microsoft identified an issue in applications that use HCS-managed Linux virtual machines and share Windows-host folders into those Linux environments through Plan9. In plain terms, a program’s Linux-based workspace could no longer reliably reach files stored on the Windows PC when it depended on this particular host-folder-sharing mechanism.
Microsoft explicitly identified both Claude Cowork and Windows Subsystem for Linux (WSL) among the affected applications. That is meaningful because the visible symptom varied by workflow. For a developer, it might have appeared as a build script, repository operation, or command-line tool losing access to a project directory on the Windows drive. For a Claude Cowork user, it meant a local-workspace feature could no longer complete tasks requiring commands to run against files on the PC.
Anthropic described the Cowork consequence more precisely: after the September 8 Windows update, Cowork on Windows could not run local commands because its workspace could not reach the computer’s drive. It also said that, for most users, chat plus file reading and editing continued to work. So this was not necessarily a full application outage. It was a loss of a high-value capability: the ability to perform local command-driven work.
That distinction matters. Users who only used Cowork for conversation or ordinary document interaction may not have seen a problem. Users asking it to carry out local coding, automation, or workspace tasks were more likely to be blocked.
The scope was narrower than “Linux and VMs are broken”
The affected technical path is easy to overgeneralise. This was not evidence that Windows 11 broke every virtual machine, every Linux installation, or Hyper-V as a whole.
Microsoft’s description specifically concerns Plan9-based Windows-host folder sharing in Linux VMs managed through the Host Compute Service (HCS). It also explicitly says that standard Hyper-V virtual machines that do not use Plan9 are unaffected.
That leaves an important practical boundary:
- A user running a conventional Hyper-V VM without this sharing arrangement should not assume they are affected.
- A WSL or custom Linux-based application that depends on the relevant host-folder-sharing path could be affected.
- An application failure after KB5124008 should not automatically be attributed to this issue just because it involves Linux, containers, WSL, or virtualisation.
Independent testing reported that KB5129195 restored functionality in both Claude Cowork and custom WSL-based applications. That is encouraging confirmation beyond the vendor release notes, but it should not be read as a guarantee for every third-party workflow. Custom development environments can combine file mounts, security tools, network paths, container layers, and policy settings in ways that differ from the tested scenario.
For affected users, the most sensible first step is to install KB5129195, restart if Windows requests it, then retest the exact local command or host-folder workflow that failed. Testing a simple file listing or edit is not always enough: the original Cowork symptom concerned local command execution, so users should verify the operation that was actually blocked.
Remote Desktop Services was the higher-stakes regression
The same September update was also associated with Remote Desktop Services instability. Microsoft describes potential RDP connection failures, sign-in problems, and servers becoming unresponsive during Remote Desktop configuration.
For a home PC, an RDP failure can be an inconvenience. For a managed workstation, shared server, help-desk environment, or business that relies on remote administration, the consequences are more serious. Failed sign-ins can interrupt routine access; an unresponsive server during configuration can turn a normal maintenance window into an operational incident.
KB5129195 addresses the RDS issue as well. Organisations that paused deployment of the September update, rolled back systems, or applied a temporary workaround should validate the out-of-band update in their normal test ring before broad deployment. The update is offered automatically through Windows Update, but managed environments may defer, approve, or otherwise regulate it through business policy. In those environments, “available from Windows Update” does not necessarily mean “already installed everywhere.”
Administrators should confirm the installed build after deployment:
- Windows 11 24H2 should reach build 26100.9457.
- Windows 11 25H2 should reach build 26200.9457.
They should then test the connection and sign-in paths their organisation actually uses, rather than relying only on a successful installation report. A local RDP connection, a remote connection through a gateway, and a sign-in using an enterprise identity can exercise different parts of the environment.
USB audio: one repair, several open problems
KB5129195 also includes a fix for a specific USB Audio Class 1.0 symptom: multichannel 8-channel or 3D audio. Users whose affected device problem is limited to that scenario have a reason to expect improvement after installing the emergency update.
However, this is not a complete USB audio repair. Microsoft continues to list other USB Audio Class 1.0 issues as unresolved, including devices showing a Code 10 error, no audio output, unresponsive volume controls, and unavailable sound settings.
This is the key troubleshooting trap to avoid. A user may install KB5129195, see that Windows has reached the new build number, and reasonably expect every audio symptom connected to the September release to disappear. Microsoft’s own status information does not support that expectation.
If a device still reports Code 10 or produces no sound after the update, the remaining issue may be one Microsoft is still working on rather than evidence that the out-of-band update failed to install. Conversely, not every USB audio fault is necessarily caused by this Windows regression; cables, devices, drivers, docks, and audio settings can all introduce separate failures. The supported conclusion is narrower: KB5129195 resolves the multichannel/3D-audio symptom, while the other listed USB Audio Class 1.0 symptoms remain open.
Documentation quirks make careful diagnosis important
Microsoft’s published material contains inconsistent internal cross-references around these September issues. One support-page passage links the RDS regression to a different KB number even though the September KB5124008 documentation and Windows release-health information associate the regression with that update. The USB audio documentation similarly contains a discrepancy: one support-page passage refers to a different originating KB, while the Windows release-health dashboard identifies KB5124008.
Those inconsistencies do not establish that a different update caused the incidents. But they are a reason to focus on the symptoms, the affected Windows versions, and the fixed build numbers rather than treating every KB cross-link as definitive root-cause proof.
For end users, this means checking whether the device is running 24H2 or 25H2 and whether it has reached the KB5129195 build is more useful than trying to reconcile every reference in release notes. For IT teams, it is a reminder to preserve incident timelines and test results locally, especially if update approval or rollback decisions depend on pinpointing the first bad build.
Reports that should not be treated as confirmed fixes or regressions
Some reporting has mentioned possible Explorer, File History, and AMD GPU issues following the September update. There were reports of AMD Radeon-related problems, but the available evidence does not confirm a KB5124008 Radeon driver defect. Microsoft’s documented known issues do not establish one, and no AMD confirmation is established here.
Users experiencing a GPU issue should therefore avoid assuming that KB5129195 is designed to fix it—or that the September Windows update is proven to be the cause. The emergency update’s documented fixes are the RDS problem, the HCS/Plan9 host-folder-sharing problem, and the limited USB multichannel/3D-audio symptom.
The same caution applies to claims about the scale of the September security release. A reported total of 974 vulnerabilities applied to Microsoft’s wider September 2026 Patch Tuesday portfolio across the company’s products. That figure should not be presented as the number fixed by KB5124008 alone.
What Windows 11 users should do now
For most people, the action plan is modest: allow Windows Update to install KB5129195, or have the organisation responsible for the PC deploy it under its existing policy. Then confirm that the machine is on the appropriate updated build and test the affected workflow.
Users of Claude Cowork or WSL should specifically retry the local task that required access to files stored on Windows. If it now works, the Plan9 host-folder-sharing regression is likely resolved for that workflow. If it does not, the problem may be different from the documented issue, or it may involve a custom environment that needs further investigation.
Remote Desktop users and administrators should perform a deliberate connection and sign-in test after updating. Because the reported RDS problem could affect availability during configuration, this deserves more care than a casual check that the Remote Desktop app opens.
USB Audio Class 1.0 users should set expectations based on the exact symptom. Multichannel or 3D-audio trouble is the issue KB5129195 is meant to fix. Code 10 errors, absent output, frozen volume controls, and missing sound settings remain in the unresolved category.
The episode is a useful illustration of why cumulative-update quality is not just about whether Windows boots. A regression in host-folder sharing can disable developer tools and local AI workflows without making the underlying Windows desktop appear obviously broken. An RDS issue can have a much larger business impact than its short release-note description suggests. KB5129195 provides a targeted repair for both, but users should judge success against the problem they actually encountered—not against the assumption that every post-update complaint has the same cause or the same fix.