[BUG] VS Code extension v2.1.136 (win32-x64) fails to activate — hardcoded Linux CI path in createRequire (regression of #56549, #56725)

I independently reproduced the same regression on Windows and accidentally opened #57416 a moment after this issue. Adding the extra evidence here so the signal stays consolidated.

Environment from my repro:

OS: Microsoft Windows 11 Pro 10.0.26200, x64
VS Code: 1.119.0, x64
Extension: anthropic.claude-code 2.1.136 win32-x64
Last working extension version on the same machine: 2.1.133
Bundled native binary: 2.1.136 (Claude Code)

Activation failure from the VS Code Extension Host log:

ExtensionService#_doActivateExtension Anthropic.claude-code, startup: false, activationEvent: 'onStartupFinished'
Activating extension Anthropic.claude-code failed due to an error:
TypeError: The argument 'filename' must be a file URL object, file URL string, or absolute path string. Received 'file:///home/runner/work/claude-cli-internal/claude-cli-internal/build-agent-sdk/sdk.mjs'
    at Module.createRequire (node:internal/modules/cjs/loader:1922:13)
    at Object.<anonymous> (%USERPROFILE%\.vscode\extensions\anthropic.claude-code-2.1.136-win32-x64\extension.js:103:5579)

Static inspection of the installed bundle mapped that location to a top-level call equivalent to:

J$.createRequire("file:///home/runner/work/claude-cli-internal/claude-cli-internal/build-agent-sdk/sdk.mjs")

Local diagnostic patch tested:

- J$.createRequire("file:///home/runner/work/claude-cli-internal/claude-cli-internal/build-agent-sdk/sdk.mjs")
+ J$.createRequire(__filename)

After reloading VS Code, the extension activated successfully again. This is only a local diagnostic workaround, not a recommended user fix, but it confirms the activation failure is caused by the packaged top-level createRequire(...) argument rather than auth, settings, MCP config, installation corruption, or the bundled claude.exe.

I will close #57416 as a duplicate of this issue.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/57397
2. https://github.com/anthropics/claude-code/issues/57389
3. https://github.com/anthropics/claude-code/issues/57416

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Confirming on Windows 11 Enterprise, VS Code extension 2.1.136-win32-x64. Same createRequire TypeError with the
file:///home/runner/work/claude-cli-internal/... path at extension.js:103:5579. Auto-update pushed 2.1.136 ~2 hours
ago and broke activation; downgrading to the prior working version and disabling auto-update works around it. Please
prioritize — this is the second time this regression has shipped.

Claude VsCode extension is bricked on Windows for me as well.
Same exact issue happened with v2.1.129 a few days ago: https://github.com/anthropics/claude-code/issues/56504
Reverting back to 2.1.133 with a manual installation resolved it for me.

Adding an evidence point that may shift the framing of the fix.

I just diagnosed this on Windows 11 Home (build 26200), VS Code 1.119.0, also recovered by rolling back to 2.1.133. Standard reproduction, nothing new there.

What's worth flagging: the hardcoded Linux path is also present in the working 2.1.133 bundle, not just in 2.1.136. Verified by grepping the installed extension.js:

let A = H.pathToClaudeCodeExecutable;
if (!A) {
    let F8 = xl.fileURLToPath("file:///home/runner/work/claude-cli-internal/claude-cli-internal/build-agent-sdk/sdk.mjs");
    let g8 = Gl.createRequire(F8);
    ...
}

So the latent bug has been in the bundle the whole time. The reason 2.1.133 works is that the if (!A) fallback branch is never taken — pathToClaudeCodeExecutable is populated correctly from the bundled resources\native-binary\claude.exe (225 MB) and passed to the SDK. Confirmed in my Claude VSCode log:

Spawning Claude with SDK query function ...
c:\Users\...\.vscode\extensions\anthropic.claude-code-2.1.133-win32-x64\resources\native-binary\claude.exe

What 2.1.136 must have changed is something upstream that makes pathToClaudeCodeExecutable fall through as falsy on Windows — either (a) the native binary stopped being packaged in the win32-x64 VSIX, (b) the resolver that builds the path got reworked and broke on Windows, or (c) the SDK destructuring dropped the field. Then the latent fallback fires and explodes.

This means the suggested fix needs two parts, not one:

1. The immediate fix proposed above — make the createRequire argument resolve at runtime (e.g. __filename, or platform-aware) — which removes the booby trap for good.
2. A separate fix for whatever regression in 2.1.136 caused pathToClaudeCodeExecutable to stop being passed on Windows in the first place — otherwise even with #1 patched, users would silently fall through to a less-optimal codepath.

Tracking only #1 risks shipping 2.1.137 that "works" but is structurally identical to 2.1.133 (i.e., still one upstream regression away from the next outage). The regression test suggested in the issue body should explicitly assert that pathToClaudeCodeExecutable is truthy when SDK query() is invoked from the packaged win32-x64 extension, not just that activation succeeds.

Have the same Issue...

same issue in antigravity

Confirmed on Windows - same symptoms: Activity Bar icon missing,
commands not found, model selector broken. Rolled back to 2.0.62.

+1, reproducible on Windows 11 (x64) with extension v2.1.136.

Environment

• VSCode: (please fill in your version)
• Extension: anthropic.claude-code 2.1.136-win32-x64
• OS: Windows 11 x64

Symptom

• Status bar ✻ Claude Code click → toast command 'claude-vscode.editor.openLast' not found
• All Claude Code commands missing from Command Palette

Root cause (from exthost.log)

Thanks for reporting! We believe we have resolved this issue in v2.1.137 which is available now. Please update to pick up the fix.

This issue was fixed as of version 2.1.137.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.