[BUG] CoworkVMService fails on Windows with non-ASCII username path (ã) — signature verification cannot resolve executable path

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?

Environment

• Claude Desktop version: 1.1.8359.0
• Windows version: Windows 11 Pro
• Username path: C:\Users\Lucas Requião (contains ã)
• Subscription: Pro

What's Wrong

CoworkVMService fails to start on every attempt. The service initializes,
loads HCS/HCN DLLs successfully, but crashes at signature verification
because it cannot resolve the executable path due to encoding corruption
of the ã character in the Windows username.

Error in cowork-service.log

Service error: signature verification initialization failed:
failed to get service executable path:
O sistema não pode encontrar o caminho especificado.

Note: "não" is "não" with ã corrupted — confirming the encoding bug.

Reproducing the encoding issue

Running this PowerShell command:
[System.Text.Encoding]::UTF8.GetString(
[System.Text.Encoding]::Default.GetBytes(
"C:\Users\Lucas Requião\AppData\Roaming\Claude"
)
)

Returns:
C:\Users\Lucas Requi<EFBFBD>o\AppData\Roaming\Claude

The ã is being corrupted before the path is passed to the service.

What was tried

• Installed Claude Desktop as Administrator
• Enabled Microsoft-Hyper-V-All via PowerShell
• Confirmed HyperVisorPresent = True (AMD CPU, SVM enabled)
• Confirmed VirtualMachinePlatform = Enabled
• Manually created AppData\Roaming\Claude folder
• Attempted to redirect APPDATA via environment variables
• Attempted to start CoworkVMService directly via PowerShell

None of these resolved the issue. The root cause is the ã character
in the Windows username path being corrupted in the service's
internal path resolution.

Related Issues

#35366 (Korean username path causes same class of bug)

Expected Behavior

CoworkVMService should handle non-ASCII characters in Windows
username paths, or at minimum display a clear error message
informing the user that their username contains unsupported characters.

What Should Happen?

CoworkVMService should correctly handle non-ASCII characters (such as
accented letters like ã, ñ, ü, etc.) in Windows username paths.

The service should either:

1. Use Unicode-safe path resolution internally, so that usernames

containing accented characters are processed without encoding
corruption, or

1. Display a clear, actionable error message in the UI informing

the user that their username contains characters that are not
yet supported, instead of silently failing with a cryptic
"signature verification" error.

Currently, the ã in "Requião" is corrupted to garbled characters
internally, causing the service to be unable to locate its own
executable path and failing immediately on every start attempt.
There is no workaround available without creating a new Windows
user account with an ASCII-only name, which is not a reasonable
expectation for users whose native language uses accented characters
(Portuguese, Spanish, French, German, etc.).

Error Messages/Logs

Steps to Reproduce

1. Have a Windows 11 Pro system with a username containing

non-ASCII characters (e.g. "Lucas Requião" — contains ã)

1. Install Claude Desktop (MSIX) as Administrator from

https://claude.ai/download

1. Open Claude Desktop and navigate to the Cowork tab

1. Observe that the Cowork tab keeps loading indefinitely

and then restarts Claude Desktop

1. Open PowerShell as Administrator and attempt to start

the service manually:

Start-Service CoworkVMService

Result: "Falha ao iniciar o serviço 'Claude (CoworkVMService)'"
(Service failed to start)

1. Read the service log to confirm the root cause:

Get-Content "C:\ProgramData\Claude\Logs\cowork-service.log" -Tail 20

Result:
Service error: signature verification initialization failed:
failed to get service executable path:
O sistema não pode encontrar o caminho especificado.

Note: "não" is the UTF-8 corruption of "não" (Portuguese for
"not") — confirming the ã encoding bug.

1. Confirm the encoding corruption with PowerShell:

[System.Text.Encoding]::UTF8.GetString(
[System.Text.Encoding]::Default.GetBytes(
"C:\Users\Lucas Requião\AppData\Roaming\Claude"
)
)

Result:
C:\Users\Lucas Requi<EFBFBD>o\AppData\Roaming\Claude

The ã character is corrupted before being passed to the service.

Additional Diagnostic Info

HyperVisorPresent: True
HyperVRequirementVirtualizationFirmwareEnabled: True
Microsoft-Hyper-V-All: Enabled
VirtualMachinePlatform: Enabled
CPU: AMD (SVM enabled in BIOS)

The issue is NOT related to Hyper-V configuration or hardware
virtualization support — all prerequisites are met. The sole
cause is the non-ASCII character in the username path.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop version: 1.1.8359.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_