[BUG] VS Code extension fails to spawn `claude` binary when workspace folder is under a OneDrive-synced path (misleading "musl/glibc" error on Windows)

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?

Description:

When the open VS Code workspace folder lives inside a OneDrive-synced directory (in this case, an OneDrive-redirected Desktop — a common default on new Windows setups), the extension fails to spawn the claude process. The error message is misleading: it describes a musl-vs-glibc dynamic linker mismatch, which is a Linux-only concept and doesn't apply on Windows at all. The underlying OS error (visible earlier in the same log) is actually ENOENT on the executable path — even though the executable file demonstrably exists and runs fine standalone.

Opening the exact same binary configuration in a plain, non-OneDrive folder (e.g. C:\Projects\test) works without any changes. Only the location of the workspace folder (and therefore the cwd passed to the spawn call) differs between the failing and working cases.

What Should Happen?

Expected: Claude launches normally.
Actual: Spawn fails every time with the log sequence below.

Error Messages/Logs

**Log excerpt** (from "Claude Code: Show Logs"; paths redacted):

[error] claude auth status spawn failed: Error: spawn C:\Users\<user>\.local\bin\claude.exe ENOENT
[error] claude auth status parse failed: SyntaxError: Unexpected end of JSON input
[info] Spawning Claude with SDK query function - cwd: c:\Users\<user>\OneDrive\Desktop\<project>, permission mode: undefined, version: 2.1.269, C:\Users\<user>\.local\bin\claude.exe, resume: undefined
[error] Error spawning Claude (on channel <channel-id>): ReferenceError: Claude Code native binary at C:\Users\<user>\.local\bin\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. Specify a matching binary with options.pathToClaudeCodeExecutable.
[error] Failed to load config cache: ReferenceError: Claude Code native binary at C:\Users\<user>\.local\bin\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. Specify a matching binary with options.pathToClaudeCodeExecutable.

Steps to Reproduce

Steps to reproduce:

1. On Windows, open a VS Code workspace folder that lives under an OneDrive-synced path (e.g. C:\Users\<user>\OneDrive\Desktop\<project>), with all files fully downloaded/hydrated locally (not cloud-only placeholders).
2. Install the Claude Code VS Code extension and sign in.
3. Attempt to open the Claude Code panel / send a prompt.

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.269

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Environment:

• OS: Windows 10/11
• VS Code extension version: anthropic.claude-code-2.1.269-win32-x64
• Both the extension's bundled binary and a separately-installed standalone CLI (%USERPROFILE%\.local\bin\claude.exe, verified working via claude --version when run directly) fail identically when spawned by the extension

Note the same failure occurred both with the extension's own bundled binary (...\extensions\anthropic.claude-code-2.1.269-win32-x64\resources\native-binary\claude.exe) and after pointing claudeCode.claudeProcessWrapper at a separately installed, independently-verified-working standalone CLI at C:\Users\<user>\.local\bin\claude.exe — the only constant across both failures was the cwd being inside the OneDrive-synced folder.

Troubleshooting already ruled out:

• Antivirus/Windows Defender: no blocks or quarantine events found
• Corrupted download: standalone binary verified with matching file size and successful --version output when run directly from a terminal
• Stale extension state: confirmed after full extension reinstall, VS Code restart, and full OS reboot
• claudeProcessWrapper misconfiguration: confirmed the JSON setting and target path were correct

Suggested fix: When a spawn fails, surface the actual underlying OS error (e.g. ENOENT, EACCES) rather than always showing the generic musl/glibc message, which is inapplicable on Windows and actively misleads troubleshooting. It would also help to detect and warn when the workspace cwd sits inside a cloud-sync-managed folder (OneDrive, Dropbox, etc.), since this is an increasingly common source of odd spawn failures with Windows dev tools generally.