[BUG] Cowork Workspace Fails on Windows with Dot in Username (EBADF on rootfs.vhdx rename)

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?

Application: Claude Desktop + Cowork (CoworkVMService)
Version: Claude_1.1.6452.0_x64__pzs8sxrjxfjjc
OS: Windows 10/11 (corporate domain-joined)
Date reported: March 16, 2026
Status: ❌ Unresolved

---

Summary

When attempting to initialize the Cowork workspace in Claude Desktop, the application consistently fails with the following error:

EBADF: bad file descriptor, rename 'C:\Users\FIRST~1.LAS\AppData\Local\Temp\wvm-xxx\rootfs.vhdx'
-> 'C:\Users\firstname.lastname\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

The user-facing message is:

Could not start the Claude workspace.
ClaudeVM service not running. The service failed to start.

The error reproduces consistently on every attempt. The rootfs.vhdx file (~8 GB) downloads successfully to a temporary folder, but the application fails when attempting to move it to its final destination via a rename operation.

---

Environment

| Field | Value |
|-------|-------|
| Affected user | firstname.lastname |
| Machine | Windows 10/11 corporate (domain-joined) |
| Application | Claude Desktop + Cowork |
| Claude version | Claude_1.1.6452.0_x64__pzs8sxrjxfjjc |
| Service executable | C:\Program Files\WindowsApps\Claude_1.1.6452.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe |
| Service type | WIN32_PACKAGED_PROCESS (UWP) |
| Service dependencies | staterepository |
| Node.js | v24.13.1 |
| npm | 11.8.0 |
| Antivirus | Kaspersky Endpoint Security (centrally managed via Kaspersky Security Center) |
| Temp path (source) | C:\Users\FIRST~1.LAS\AppData\Local\Temp\wvm-xxx\rootfs.vhdx |
| Destination path | C:\Users\firstname.lastname\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx |
| rootfs.vhdx size | ~8 GB (fully downloaded before the rename fails) |
| Registry keys using 8.3 alias | 371 (per fsutil 8dot3name strip /s C:) |

---

Root Cause Analysis

1. Windows 8.3 short name alias

The username contains a dot (firstname.lastname). Windows automatically generates a short 8.3 alias for this profile: FIRST~1.LAS. Both names point to the same physical folder, but Node.js (the runtime used internally by Cowork) treats them as different paths when executing the rename operation.

The sequence is:

1. Cowork downloads rootfs.vhdx to a temporary folder using the short alias path: C:\Users\FIRST~1.LAS\AppData\Local\Temp\wvm-xxx\
2. It attempts to move the file to the destination using the long name: C:\Users\firstname.lastname\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\
3. Node.js calls fs.rename() with both paths. When it detects that source and destination appear to be on different devices (because the path strings differ), it fails with EBADF instead of performing an atomic rename.
4. Cowork catches the failure, deletes the temp files, and shows the error to the user.

This is a compatibility bug between the Cowork installer and Windows environments where the username contains special characters (dots, hyphens, etc.) that generate 8.3 aliases. It is particularly common in corporate environments where usernames follow the firstname.lastname format.

2. Kaspersky Endpoint Security (secondary factor)

In parallel, Kaspersky Endpoint Security — centrally managed by IT via Kaspersky Security Center — actively blocked several steps of the installation process:

• Blocked the .vhdx rename operation in real time.
• Automatically disabled the CoworkVMService service seconds after it was installed.
• Prevented manual modification of the service from PowerShell even with local administrator privileges.

After IT applied exclusions in Kaspersky Security Center, the service was able to start. However, the EBADF rename error persists, confirming that the 8.3 alias conflict is an independent bug that exists regardless of antivirus interference.

---

What Should Happen?

Option A — Normalize paths before rename (recommended)

The Cowork installer should normalize both paths to the same form (long name or short name) before executing the rename. The Windows API call GetLongPathName() can resolve the 8.3 alias to its long name equivalent before passing the paths to Node.js.

Pseudocode:

const sourcePath = getLongPathName(tempVhdxPath);   // resolves FIRST~1.LAS -> firstname.lastname
const destPath = getLongPathName(destVhdxPath);
fs.renameSync(sourcePath, destPath);

Option B — Copy + delete fallback

As a temporary workaround, the installer could substitute the atomic rename for a copy + delete operation when it detects that the paths have different string representations for the same route. This is less efficient but avoids the EBADF error entirely.

---

Error Messages/Logs

EBADF: bad file descriptor, rename 'C:\Users\FIRST~1.LAS\AppData\Local\Temp\wvm-xxx\rootfs.vhdx'
-> 'C:\Users\firstname.lastname\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

Steps to Reproduce

This bug is reproducible on any Windows machine where:

1. The username contains a dot or other special character that generates a Windows 8.3 alias (e.g. john.doe → JOHN~1.DOE).
2. Windows 8.3 short names are enabled on the filesystem (Windows default).

To reproduce:

1. Create a test user with a dot in the username (e.g. test.user) on Windows 10/11.
2. Install Claude Desktop + Cowork.
3. Attempt to initialize the workspace.
4. Observe the EBADF error on the rootfs.vhdx rename.

---

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude_1.1.6452.0_x64__pzs8sxrjxfjjc

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• The bug affects any Windows installation where the username contains characters that generate a Windows 8.3 alias (dots, hyphens, certain special characters). This is extremely common in corporate environments using firstname.lastname username formats.
• The rootfs.vhdx file downloads fully and correctly every time (~8 GB). The failure happens exclusively at the rename/move step.
• The issue persists even with Kaspersky fully paused and local administrator privileges confirmed. Kaspersky is a secondary complication in this case, not the root cause of the rename failure.
• Disabling 8.3 short names system-wide (fsutil 8dot3name set C: 1) is not viable in this environment due to 371 existing registry key dependencies.

Timeline

Phase 1 — First error and initial diagnosis (March 13, 2026)

First error observed:

EBADF: bad file descriptor, rename 'C:\Users\FIRST~1.LAS\AppData\Local\Temp\wvm-AozHzQ\rootfs.vhdx'
-> 'C:\Users\firstname.lastname\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

The 8.3 alias conflict was identified as the likely cause. Verified with:

cmd /c "dir /x C:\Users" | Select-String "firstname"

Attempted to configure exclusions in Windows Defender via PowerShell:

Add-MpPreference -ExclusionPath "C:\Users\firstname.lastname\AppData\Roaming\Claude"

Result: Error 0x800106ba. The Windows Defender service was stopped. Confirmed that Kaspersky Endpoint Security, as the active corporate security solution, had disabled Defender.

Attempted to configure exclusions directly in Kaspersky from the local interface. The Threats and Exclusions menu was inaccessible — all configuration options were locked for the end user because the policy is centrally managed.

Attempted to pause Kaspersky from the system tray. The system prompted for an IT administrator password. The user does not have it.

Phase 2 — Reinstallation and new error (March 13, 2026, afternoon)

Performed a full reinstall of Claude Desktop. After reinstallation, a new error appeared:

ClaudeVM service not running. The service failed to start.

Diagnosed the CoworkVMService status via PowerShell:

Get-Service | Where-Object {$_.DisplayName -like "*Claude*"}

The service appeared as Stopped. Attempted to start it:

Start-Service -Name "CoworkVMService"

Result: Error — "Cannot start the service CoworkVMService on computer '.'".

Checked the Windows System Event Log and found these critical entries:

10:56:45 — Service Claude installed.
           Binary: C:\Program Files\WindowsApps\Claude_1.1.6452.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

10:56:45 — Service startup type changed from Automatic to Disabled.
           (No user action performed.)

14:26:57 — The service terminated unexpectedly.

This confirms that Kaspersky detected the newly installed service and automatically disabled it by policy.

An IT ticket was raised with full documentation, requesting: (1) Kaspersky exclusions for the relevant paths and the cowork-svc.exe executable, and (2) re-enabling the CoworkVMService.

Phase 3 — IT intervention and further attempts (March 16, 2026)

IT applied exclusions in Kaspersky Security Center. With the antivirus still active, attempted to re-enable the service:

Set-Service -Name "CoworkVMService" -StartupType Automatic

Result: Access denied.

Tried with sc.exe:

sc.exe config CoworkVMService start= auto

Result: [SC] OpenService ERROR 5: Access is denied.

Verified that the user has local administrator privileges:

whoami /groups | findstr "S-1-5-32-544"

BUILTIN\Administrators was present and enabled. The access denied error was not caused by insufficient Windows privileges — it was Kaspersky actively protecting the service.

Attempted to modify the registry directly as a workaround:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService" /v Start /t REG_DWORD /d 2 /f

Result: "The operation completed successfully." However, Start-Service continued to fail afterwards.

IT paused Kaspersky temporarily by entering the admin password. With Kaspersky paused, Set-Service and Start-Service were retried — both still returned Access Denied, indicating the block was not exclusively from Kaspersky.

Claude Desktop was opened directly. The CoworkVMService started automatically upon launching the application (correct behavior for WIN32_PACKAGED_PROCESS type services). Get-Service showed status Running.

However, when attempting to load the workspace, the original EBADF rename error reproduced again.

Phase 4 — Rename investigation and file capture (March 16, 2026)

A real-time monitoring script was designed to capture the .vhdx file in the temp folder before Claude deleted it upon failure:

while ($true) {
    $f = Get-ChildItem "C:\Users\firstname.lastname\AppData\Local\Temp" -Filter "wvm-*" -Directory `
       | Sort-Object LastWriteTime -Descending | Select-Object -First 1
    if ($f) { Get-ChildItem $f.FullName | Select-Object Name, Length; break }
    Start-Sleep -Milliseconds 500
}

Confirmed that the file downloads correctly and grows progressively to ~8 GB before the rename fails. The file reaches its full size — this is not a truncated download issue.

Sample of file sizes captured across multiple attempts:

| Attempt | rootfs.vhdx | rootfs.vhdx.zst |
|---------|-------------|-----------------|
| 1 | 1,786,085,376 bytes | 469,762,048 bytes |
| 2 | 3,909,189,632 bytes | 826,277,888 bytes |
| 3 | 6,452,920,320 bytes | 1,635,778,560 bytes |
| 4 | 8,240,054,272 bytes | 2,055,208,960 bytes |

An interception script was tried to move the file manually before Claude attempted the rename:

while ($true) {
    $f = Get-ChildItem "C:\Users\firstname.lastname\AppData\Local\Temp" -Filter "wvm-*" -Directory `
       | Sort-Object LastWriteTime -Descending | Select-Object -First 1
    if ($f) {
        $vhdx = Join-Path $f.FullName "rootfs.vhdx"
        if (Test-Path $vhdx) {
            $size1 = (Get-Item $vhdx).Length
            Start-Sleep -Seconds 3
            $size2 = (Get-Item $vhdx).Length
            if ($size1 -eq $size2 -and $size1 -gt 1GB) {
                Move-Item $vhdx "C:\Users\firstname.lastname\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx" -Force
                break
            }
        }
    }
    Start-Sleep -Milliseconds 500
}

The file was moved successfully in one attempt, but Claude started a new download anyway because it detected that its own rename process had failed.

Phase 5 — Attempts to resolve the 8.3 alias (March 16, 2026)

Attempted to strip 8.3 aliases from the disk to force Windows to always use the long name:

fsutil 8dot3name strip /s C:

Result: Error. 371 registry keys reference 8.3 names. Log generated at:

C:\Users\FIRST~1.LAS\AppData\Local\Temp\8dot3_removal_log @(GMT 2026-03-16 11-36-24).log

This operation was ruled out due to the risk of breaking corporate applications that depend on those 371 registry paths.

Attempted to create a symbolic link to unify the paths. When verified, FIRST~1.LAS already points to the same physical location as firstname.lastname, so a symbolic link adds nothing.

---