[BUG] VS Code extension activates in virtual workspaces and shows a misleading "native binary failed to launch (libc)" error

Status Open
Reported on v2.1.281
Maintainer reply None cached
Activity 5 comments · opened Sep 23, 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?

In a VS Code virtual workspace (no local filesystem — e.g. the GitLab Workflow extension's "Open Remote Repository", or the built-in Remote Repositories / github.dev), the Claude Code pane activates and immediately fails with a misleading error. The bundled binary is fine; there is just no local working directory for it to run against.

The libc/musl text is wrong for this case (and irrelevant on Windows). The real cause is the virtual workspace, not a binary mismatch.

What Should Happen?

The Claude Code plugin should not attempt to start when starting in a virtualWorkspace.

Root cause

  • The extension does not declare capabilities.virtualWorkspaces in package.json, so VS Code treats it as fully supported and activates it (onStartupFinished) in virtual-workspace windows.
  • The native binary needs a real local file:-scheme working directory. A virtual workspace root is a non-file: URI, so the spawn fails.

Requested fix: Declare virtual-workspace support explicitly:

"capabilities": {
  "virtualWorkspaces": { "supported": false, "description": "Claude Code requires a local workspace." }
}

This lets VS Code auto-disable the extension in virtual workspaces and show the standard "limited" badge, instead of activating it and surfacing an incorrect libc error. ("limited" would be an alternative if partial functionality is intended.)

Error Messages/Logs

ReferenceError: Claude Code native binary at ...\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. Specify a matching binary with
options.pathToClaudeCodeExecutable.

Steps to Reproduce

  1. Windows 11, extension anthropic.claude-code 2.1.281.
  2. GitLab Workflow extension -> "Open Remote Repository" (browse a repo without cloning).
  3. Claude Code pane in the new window shows the error above.
  4. The pane works normally in a regular local-folder window, and claude.exe --version runs fine standalone (exit 0) — confirming the binary is not the problem.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code plugin for VS Code 2.1.281

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

3 Comments

Korochenkov · 20 days ago

I have the same error, @gangd004 Do you know workaround?

gangd004 · 19 days ago

@Korochenkov The only workaround I know of is to close the Claude Code tab in the virtual workspace at this time.

enzogram · 17 days ago

Issue confirmed. I am running version 2.1.283, macOS arm64. Same issue.

Showing cached comments. Read the full discussion on GitHub ↗