claude-code - 💡(How to fix) Fix [BUG] Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied. [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#56195Fetched 2026-05-06 06:34:39
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
labeled ×5

Error Message

2026/04/29 16:34:23.153997 [Server] Starting named pipe server on \.\pipe\cowork-vm-service 2026/04/29 16:34:23.153997 Service error: failed to start server: failed to create named pipe: open \.\pipe\cowork-vm-service: Access is denied.

2026/05/01 17:03:09.445231 [Server] Starting named pipe server on \.\pipe\cowork-vm-service 2026/05/01 17:03:09.445766 Service error: failed to start server: failed to create named pipe: open \.\pipe\cowork-vm-service: Access is denied.

2026/05/05 01:28:08.229376 [Server] Starting named pipe server on \.\pipe\cowork-vm-service 2026/05/05 01:28:08.229907 Service error: failed to start server: failed to create named pipe: open \.\pipe\cowork-vm-service: Access is denied.

Fix Action

Fix / Workaround

No user-side workaround is viable. As noted in #27010 and #36590, MSIX-packaged services cannot be reconfigured via sc.exe or Set-Service from elevated PowerShell, so changing the service type to WIN32_OWN_PROCESS locally is not an option. This needs to be fixed in the package manifest.

Code Example

OS: Windows 11 Pro 24H2 (Build 26100)
Claude Desktop: 1.5354.0.0 (MSIX, SignatureKind: Developer)
Package: Claude_1.5354.0.0_x64__pzs8sxrjxfjjc
Install location: C:\Program Files\WindowsApps\ (no D: symlinks, no EXDEV path)
Microsoft-Hyper-V-All: Enabled
HypervisorPlatform: Enabled
VirtualMachinePlatform: Enabled
vmms service: Running
User in Hyper-V Administrators: Yes
VM bundle: present (claudevm.bundle)

---

2026/04/29 16:34:23.153997 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
2026/04/29 16:34:23.153997 Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied.

2026/05/01 17:03:09.445231 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
2026/05/01 17:03:09.445766 Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied.

2026/05/05 01:28:08.229376 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
2026/05/05 01:28:08.229907 Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied.

---

2026/05/01 17:03:09.445231 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
2026/05/01 17:03:09.445766 Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Issue logged already but thread closed due to it apparently being fixed in new download. Confirming this still reproduces on Claude 1.5354.0.0, three months after the original report against 1.2581.0.0. Failure mode is identical, including the failed to open service for recovery config: Access is denied warning and the named pipe creation failure. Claude said to post this:

Environment:

OS: Windows 11 Pro 24H2 (Build 26100)
Claude Desktop: 1.5354.0.0 (MSIX, SignatureKind: Developer)
Package: Claude_1.5354.0.0_x64__pzs8sxrjxfjjc
Install location: C:\Program Files\WindowsApps\ (no D: symlinks, no EXDEV path)
Microsoft-Hyper-V-All: Enabled
HypervisorPlatform: Enabled
VirtualMachinePlatform: Enabled
vmms service: Running
User in Hyper-V Administrators: Yes
VM bundle: present (claudevm.bundle)

The service is reaching the named pipe creation step cleanly every time. HCS DLLs load, HCN enumerates networks, signature verification initialises against the correct binary path with the Anthropic, PBC subject. Then the pipe creation fails. Three identical attempts across separate days:

2026/04/29 16:34:23.153997 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
2026/04/29 16:34:23.153997 Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied.

2026/05/01 17:03:09.445231 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
2026/05/01 17:03:09.445766 Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied.

2026/05/05 01:28:08.229376 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
2026/05/05 01:28:08.229907 Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied.

The SignatureKind: Developer also persists in 1.5354.0.0, which suggests the package is still being signed with a non-Store, non-EV certificate. Whether or not that is related to the AppContainer pipe denial, it would be worth confirming during the fix.

No user-side workaround is viable. As noted in #27010 and #36590, MSIX-packaged services cannot be reconfigured via sc.exe or Set-Service from elevated PowerShell, so changing the service type to WIN32_OWN_PROCESS locally is not an option. This needs to be fixed in the package manifest.

What Should Happen?

opening workspaces should work.

Error Messages/Logs

2026/05/01 17:03:09.445231 [Server] Starting named pipe server on \\.\pipe\cowork-vm-service
2026/05/01 17:03:09.445766 Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied.

Steps to Reproduce

  1. Install Claude Desktop using ClaudeSetup.exe from claude.ai/download on a Windows 11 24H2 machine.
  2. Enable Microsoft-Hyper-V-All, HypervisorPlatform, and VirtualMachinePlatform via Enable-WindowsOptionalFeature or Windows Features, and reboot.
  3. Add the user account to the Hyper-V Administrators local group and sign out and back in.
  4. Launch Claude Desktop and click the Cowork tab to trigger workspace setup. CoworkVMService starts as LocalSystem, runs through HCS and HCN initialisation, runs signature verification, then fails at the named pipe creation step with Access is denied.

The failure persists whether the service auto-starts or is started manually with Start-Service CoworkVMService from elevated PowerShell, and survives full reinstalls and wipes of %LocalAppData%\Claude and C:\ProgramData\Claude.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude Desktop: 1.5354.0.0 (MSIX, SignatureKind: Developer) Package: Claude_1.5354.0.0_x64__pzs8sxrjxfjjc

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

No response

extent analysis

TL;DR

The issue is likely due to the MSIX package being signed with a non-Store, non-EV certificate, causing the AppContainer pipe denial, and can be fixed by updating the package manifest.

Guidance

  • Verify that the issue is indeed related to the package signature by checking the certificate used to sign the package.
  • Investigate the possibility of updating the package manifest to use a Store or EV certificate.
  • Check the Windows Event Logs for any related errors or warnings that may provide more information about the issue.
  • Consider testing the package on a different Windows version or configuration to see if the issue is specific to Windows 11 24H2.

Example

No code snippet is provided as the issue seems to be related to the package configuration rather than code.

Notes

The issue may be specific to the MSIX packaging and the SignatureKind: Developer, and updating the package manifest may resolve the issue. However, without more information about the packaging process and the certificate used, it's difficult to provide a more detailed solution.

Recommendation

Apply workaround: Update the package manifest to use a Store or EV certificate, as this is likely to resolve the AppContainer pipe denial issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Service error: failed to start server: failed to create named pipe: open \\.\pipe\cowork-vm-service: Access is denied. [1 participants]