VS Code extension: virtual workspace folder as spawn cwd causes ENOENT, misreported as libc/binary mismatch

[juergenbaur]

Summary

In the VS Code extension, Claude Code fails to start with a misleading error when the first workspace folder is a virtual filesystem folder (non-file: scheme). The extension uses that folder's fsPath as the spawn cwd without checking it exists on disk; on Windows spawn() then fails with ENOENT, which the SDK misreports as a binary/libc problem:

ReferenceError: Claude Code native binary at ...\resources\native-binary\claude.exe exists but failed to launch.
This usually means the binary does not match this system's libc — e.g. spawning a musl-linked binary on a
glibc Linux host fails because the musl dynamic loader (/lib/ld-musl-*) is missing. ...

The binary is fine — it runs standalone and via child_process.spawn with a valid cwd (exit 0).

Environment

• Windows 11 Enterprise 10.0.22631, x64
• VS Code extension anthropic.claude-code 2.1.284 (win32-x64)
• Workspace: single root provided by an ABAP remote-filesystem extension (virtual scheme; fsPath resolves to \repotree-v1\DCR_400_..., which does not exist on disk)

Extension host log (Claude VSCode.log)

[error] claude auth status spawn failed: Error: spawn c:\Users\...\native-binary\claude.exe ENOENT
[info]  Spawning Claude with SDK query function - cwd: \repotree-v1\DCR_400_..., permission mode: undefined, version: 2.1.284, ...
[error] Error spawning Claude (...): ReferenceError: Claude Code native binary ... exists but failed to launch. ... libc ...

Root cause

In the bundled extension.js, the launch cwd is derived as (minified):

function cE($){return WY($[0]||homedir())}   // $ = workspaceFolders.map(f => f.uri.fsPath)

i.e. first workspace folder's fsPath, unconditionally. The homedir() fallback only applies when there are zero folders. For a virtual folder, uri.fsPath yields a UNC-style path that doesn't exist, so every spawn (session launch and claude auth status) fails with ENOENT, and the SDK's diagnostic wrapper attributes it to a libc mismatch.

Repro

1. Open a VS Code window whose only/first workspace root is a virtual FS folder (any FileSystemProvider-based extension; here: SAP ABAP repotree).
2. Open the Claude Code panel and start a session → error above.
3. Minimal Node repro of the mechanism:

   spawnSync('<ext>/resources/native-binary/claude.exe', ['--version'], {cwd: '\\some-virtual\path'}) // → ENOENT
   spawnSync('<ext>/resources/native-binary/claude.exe', ['--version'], {cwd: 'C:/Users/x'})            // → exit 0

Workaround

Add a real local folder to the workspace and make it the first root, then reload the window.

Suggested fix

• When picking the cwd, skip workspace folders whose scheme is not file (or whose fsPath fails fs.existsSync) and fall back to the next folder / homedir().
• Distinguish spawn ENOENT caused by a missing cwd from a missing/incompatible executable in the SDK error message — the libc hint sent the diagnosis in the wrong direction.