›_ Claude Code Issues
Claude Code Issues / #80275

[BUG] Cowork "VM connection timeout after 60 seconds" — VM boots and runs, connection never established; likely caused by non-ASCII characters in Windows username

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 22, 2026

Preflight Checklist

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

What's Wrong?

[BUG] Cowork "VM connection timeout after 60 seconds" — VM boots and runs, connection never established; likely caused by non-ASCII characters in Windows username

Summary

Cowork consistently fails to start with "VM connection timeout after 60 seconds" on Windows 11 Pro. The VM itself boots successfully (confirmed via hcsdiag list — state Running), but the app↔VM communication channel is never established. Extensive local troubleshooting rules out virtualization, firewall, antivirus, and a corrupted VM bundle.

Strong lead on root cause: Cowork worked on this same machine before a clean Windows reinstall. The only relevant difference is the Windows user profile path — previously C:\Users\joao (ASCII), now C:\Users\João Amaral (contains a non-ASCII character "ã" and a space). This suggests the VM connection setup fails to handle non-ASCII characters and/or spaces in the profile path.

Environment

  • OS: Windows 11 Pro (x64)
  • App: Claude Desktop (latest at time of report), standard installer (not Microsoft Store)
  • User profile path: C:\Users\João Amaral (non-ASCII "ã" + space)
  • Virtualization: Enabled in firmware (Task Manager shows "Virtualization: Enabled")
  • Hyper-V features: Microsoft-Hyper-V-All, Microsoft-Hyper-V, Microsoft-Hyper-V-Hypervisor, Microsoft-Hyper-V-Services, VirtualMachinePlatform, HypervisorPlatform — all Enabled
  • Antivirus: Windows Defender only (no third-party AV)

Symptoms

Every Cowork session attempt fails after ~60 s with:

Falha ao iniciar o espaço de trabalho do Claude — VM connection timeout after 60 seconds

While the app is attempting to start the workspace, hcsdiag list shows the Cowork VM booted and running:

cowork-vm-a95c3811
    VM,    Running,    8C6E4BF6-D2D7-516E-882D-89AF5E527DC7,    cowork-vm-a95c3811

(The VM does not appear in Get-VM, consistent with it being an HCS-managed VM.)

The VM bundle is intact and fully downloaded:

initrd            77 MB
initrd.zst        77 MB
rootfs.vhdx     7688 MB
rootfs.vhdx.zst 1223 MB
sessiondata.vhdx   4 MB
smol-bin.vhdx     36 MB
vmlinuz           56 MB
vmlinuz.zst       14 MB

A marker file .auto_reinstall_attempted is present, indicating the app already attempted an automatic reinstall on its own.

Troubleshooting already performed (all unsuccessful)

  1. Restarted Claude Desktop and rebooted Windows multiple times
  2. Start-Service CoworkVMService — service starts fine and shows Running; error persists
  3. Deleted %APPDATA%\Claude\vm_bundles after a reboot (files were locked while VM was mounted); bundle re-downloaded successfully (7.7 GB rootfs) — error persists
  4. Restarted Hyper-V networking/compute services: Restart-Service hns, Restart-Service vmcompute — error persists
  5. Temporarily disabled Windows Defender Firewall (all profiles) — error persists (firewall re-enabled afterwards)
  6. Verified all Hyper-V/virtualization optional features are Enabled (see Environment)
  7. No third-party antivirus installed

Key observation — regression after clean Windows reinstall

  • Before a clean Windows reinstall: Cowork worked on this exact machine. Username/profile path: C:\Users\joao (pure ASCII).
  • After the clean reinstall: Cowork has never worked. Username/profile path: C:\Users\João Amaral (non-ASCII "ã" + space).

Everything else (hardware, OS edition, virtualization config) is equivalent. This strongly suggests the host↔guest connection setup (socket path, config file path, or 9p/virtiofs share definition) breaks when the user profile path contains non-ASCII characters — the same class of bug that historically affected WSL2 and other VM tooling on Windows.

Suggested reproduction

  1. On Windows 11 Pro, create a user account whose name contains a non-ASCII character and a space (e.g., João Amaral)
  2. Install Claude Desktop under that account and start a Cowork session
  3. Observe: VM boots (visible in hcsdiag list as Running) but the app reports "VM connection timeout after 60 seconds"

Expected: workspace starts normally, as it does for ASCII-only profile paths.

Related issues

Possibly related to / duplicates of the same underlying class: #42784, #47737, #50997, #51277, #65128

Debug logs shared via the in-app "share debug logs" button.

What Should Happen?

[BUG] Cowork "VM connection timeout after 60 seconds" — VM boots and runs, connection never established; likely caused by non-ASCII characters in Windows username

Summary

Cowork consistently fails to start with "VM connection timeout after 60 seconds" on Windows 11 Pro. The VM itself boots successfully (confirmed via hcsdiag list — state Running), but the app↔VM communication channel is never established. Extensive local troubleshooting rules out virtualization, firewall, antivirus, and a corrupted VM bundle.

Strong lead on root cause: Cowork worked on this same machine before a clean Windows reinstall. The only relevant difference is the Windows user profile path — previously C:\Users\joao (ASCII), now C:\Users\João Amaral (contains a non-ASCII character "ã" and a space). This suggests the VM connection setup fails to handle non-ASCII characters and/or spaces in the profile path.

Environment

  • OS: Windows 11 Pro (x64)
  • App: Claude Desktop (latest at time of report), standard installer (not Microsoft Store)
  • User profile path: C:\Users\João Amaral (non-ASCII "ã" + space)
  • Virtualization: Enabled in firmware (Task Manager shows "Virtualization: Enabled")
  • Hyper-V features: Microsoft-Hyper-V-All, Microsoft-Hyper-V, Microsoft-Hyper-V-Hypervisor, Microsoft-Hyper-V-Services, VirtualMachinePlatform, HypervisorPlatform — all Enabled
  • Antivirus: Windows Defender only (no third-party AV)

Symptoms

Every Cowork session attempt fails after ~60 s with:

Falha ao iniciar o espaço de trabalho do Claude — VM connection timeout after 60 seconds

While the app is attempting to start the workspace, hcsdiag list shows the Cowork VM booted and running:

cowork-vm-a95c3811
    VM,    Running,    8C6E4BF6-D2D7-516E-882D-89AF5E527DC7,    cowork-vm-a95c3811

(The VM does not appear in Get-VM, consistent with it being an HCS-managed VM.)

The VM bundle is intact and fully downloaded:

initrd            77 MB
initrd.zst        77 MB
rootfs.vhdx     7688 MB
rootfs.vhdx.zst 1223 MB
sessiondata.vhdx   4 MB
smol-bin.vhdx     36 MB
vmlinuz           56 MB
vmlinuz.zst       14 MB

A marker file .auto_reinstall_attempted is present, indicating the app already attempted an automatic reinstall on its own.

Troubleshooting already performed (all unsuccessful)

  1. Restarted Claude Desktop and rebooted Windows multiple times
  2. Start-Service CoworkVMService — service starts fine and shows Running; error persists
  3. Deleted %APPDATA%\Claude\vm_bundles after a reboot (files were locked while VM was mounted); bundle re-downloaded successfully (7.7 GB rootfs) — error persists
  4. Restarted Hyper-V networking/compute services: Restart-Service hns, Restart-Service vmcompute — error persists
  5. Temporarily disabled Windows Defender Firewall (all profiles) — error persists (firewall re-enabled afterwards)
  6. Verified all Hyper-V/virtualization optional features are Enabled (see Environment)
  7. No third-party antivirus installed

Key observation — regression after clean Windows reinstall

  • Before a clean Windows reinstall: Cowork worked on this exact machine. Username/profile path: C:\Users\joao (pure ASCII).
  • After the clean reinstall: Cowork has never worked. Username/profile path: C:\Users\João Amaral (non-ASCII "ã" + space).

Everything else (hardware, OS edition, virtualization config) is equivalent. This strongly suggests the host↔guest connection setup (socket path, config file path, or 9p/virtiofs share definition) breaks when the user profile path contains non-ASCII characters — the same class of bug that historically affected WSL2 and other VM tooling on Windows.

Suggested reproduction

  1. On Windows 11 Pro, create a user account whose name contains a non-ASCII character and a space (e.g., João Amaral)
  2. Install Claude Desktop under that account and start a Cowork session
  3. Observe: VM boots (visible in hcsdiag list as Running) but the app reports "VM connection timeout after 60 seconds"

Expected: workspace starts normally, as it does for ASCII-only profile paths.

Related issues

Possibly related to / duplicates of the same underlying class: #42784, #47737, #50997, #51277, #65128

Debug logs shared via the in-app "share debug logs" button.

Error Messages/Logs

Steps to Reproduce

cowork-bug-report.md

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

v2.1.217

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Windows & WSL problems

Browse all Claude Code issue topics →