[VS Code Extension] v2.1.129 fails to activate on Windows: hardcoded Linux CI path in bundled SDK (regression)

Root-cause analysis of the bundled extension.js (v2.1.129, win32-x64)

I unpacked the win32-x64 VSIX and located two occurrences of the hardcoded CI path inside extension/extension.js. Both are produced by the same bundler defect; only the first one breaks activation because it runs at module load.

Occurrence #1 — top-level, kills activation

Around extension.js:102 (byte ~669,201):

var i2 = (V, K) => { /* ... */ },
    y20 = Ai.createRequire("file:///home/runner/work/claude-cli-internal/claude-cli-internal/build-agent-sdk/sdk.mjs"),
    yZ4 = Symbol.dispose || Symbol.for("Symbol.dispose"),
    /* ... */;

Ai is the bundled node:module. Because this createRequire(...) call is evaluated at module load, the extension throws during onStartupFinished and never registers any commands — hence command 'claude-vscode.editor.openLast' not found.

Occurrence #2 — inside CLI-resolution path, latent

Later in the bundle (byte ~1,345,663):

let Y8 = Ji.fileURLToPath("file:///home/runner/work/claude-cli-internal/claude-cli-internal/build-agent-sdk/sdk.mjs"),
    t8 = Qi.createRequire(Y8),
    a7 = iW4((QV) => t8.resolve(QV));
if (a7) W = a7;
else try { W = t8.resolve("./cli.js") } catch { throw Error(`Native CLI binary ...`) }

This branch runs the same broken pattern but inside a function (looks like the resolver for cli.js / native CLI). Even if you fix occurrence #1, this one will throw the same TypeError the moment it executes on Windows. Worth fixing both in the same change.

Why the bundler emitted these literals

In the source these almost certainly were:

// somewhere in build-agent-sdk/sdk.mjs (ESM)
import { createRequire } from 'node:module';
import { fileURLToPath } from 'node:url';
const require = createRequire(import.meta.url);
const __filename = fileURLToPath(import.meta.url);

When the ESM source build-agent-sdk/sdk.mjs is bundled into a CJS extension, import.meta.url has no CJS equivalent. esbuild (and a few other bundlers) replace it with the absolute file:// URL of the source file at build time unless you tell them otherwise. That URL only exists on the GitHub Actions runner — /home/runner/work/... — so on a user's Windows box, both node:module.createRequire(...) and node:url.fileURLToPath(...) reject the input as not pointing at a real file.

Suggested fixes (any of these works)

1. In the bundler config — replace import.meta.url with a runtime-safe expression. For esbuild:

``js
// esbuild.config.mjs
define: {
'import.meta.url': 'require("url").pathToFileURL(__filename).href',
}
``

1. In the source — don't use import.meta.url for createRequire / fileURLToPath. Use __filename (works in the CJS output and is rewritten correctly by every major bundler):

``js
import { createRequire } from 'node:module';
const require = createRequire(__filename);
``

1. Banner shim — keep import.meta.url in source, inject a runtime equivalent at the top of the CJS bundle:

``js
// esbuild banner.js
banner: {
js: var __import_meta_url = require('url').pathToFileURL(__filename).href;
}
// and post-process: import.meta.url -> __import_meta_url
``

CI gap

The fact that this exact class of bug shipped in 2.1.51, 2.1.55, 2.1.81 and now 2.1.129 means the build pipeline doesn't catch it. A one-line smoke test in CI would:

# on a Windows runner, with VS Code installed
code --install-extension ./claude-code-*-win32-x64.vsix --force
code --status   # or run a headless extensionTestsPath that just activates the extension

If activation throws, fail the build. That alone would have stopped every recurrence of this bug from ever shipping.

---
Happy to provide the unpacked extension.js byte offsets / hex dump if useful.

+1, reproduced on Windows 11 with VS Code 1.118.1 and extension v2.1.129 (win32-x64). Same TypeError at extension.js:102:5407 during the onStartupFinished activation event, so all claude-vscode.* commands fail with command not found. Downgrading to 2.1.128 restores activation.

Environment

• OS: Windows 11 Pro (10.0.22631) x64
• VS Code: 1.118.1 (user setup), commit 034f571df509819cc10b0c8129f66ef77a542f0e
• Electron: 39.8.8 / Node.js: 22.22.1 / Chromium: 142.0.7444.265
• Extension: anthropic.claude-code 2.1.129 (win32-x64)

Workaround found — downgrade to v2.1.109

Confirmed this affects all Windows users on v2.1.111–2.1.129.

Root cause: extension.js calls createRequire("file:///home/runner/work/claude-cli-internal/...") at top-level — hardcoded Linux CI path crashes on Windows immediately on activation.

Temporary fix:

1. Find your extensions folder (e.g. `D:\vscode-extensions\)
2. Delete all anthropic.claude-code-2.1.111 through 2.1.129 folders
3. Keep only anthropic.claude-code-2.1.109-win32-x64
4. Edit extensions.json in the same folder — update the Claude Code entry:

• Change "version" to "2.1.109"
• Update "fsPath" and "path" to point to the 2.1.109 folder
• Set "pinned": true to prevent auto-update back to broken version

1. Reload VS Code window

Question for the team: Is there a hotfix planned? And can pinned: true in extensions.json reliably prevent auto-update, or is there another recommended way to stay on a specific version?

Follow-up: the bug is older than the activation symptom suggests

To verify @ThinhHoangTitan's claim that 2.1.109 is "100% safe", I unpacked the win32-x64 VSIX of 2.1.109 and 2.1.128 and grepped for the same hardcoded path. Both still contain it:

| Version | Occurrences of home/runner/work/...sdk.mjs | Top-level call? | Activation breaks on Windows? |
|---|---|---|---|
| 2.1.109 | 1 | ❌ no — only inside the native-CLI resolver | ❌ no |
| 2.1.128 | 1 | ❌ no — same lazy branch as 2.1.109 | ❌ no |
| 2.1.129 | 2 | ✅ yes — top-level Ai.createRequire(...) at extension.js:102 | ✅ yes |

The lazy occurrence (present in at least 2.1.109 → 2.1.128) lives here:

let z = q.pathToClaudeCodeExecutable;
if (!z) {
  let qK = _h.fileURLToPath("file:///home/runner/work/.../build-agent-sdk/sdk.mjs"),
      O9 = Wh.createRequire(qK),
      qq = Cq4(QV => O9.resolve(QV));
  if (qq) z = qq;
  else try { z = O9.resolve("./cli.js") } catch { throw Error(`Native CLI binary for ${process.platform}-${process.arch} not found`) }
}

It only throws when the extension actually tries to resolve the bundled cli.js (i.e. the native CLI invocation path). Most chat / panel features never hit it, which is why the bug stayed dormant across ≥20 releases. 2.1.129 is just the first release where someone added a createRequire(import.meta.url) at module top-level, turning a latent bug into an activation failure.

Implications

• Recommendation in the previous comment stands: the fix should target import.meta.url handling in the bundler config, not patch only the activation-time call. Otherwise the next time someone moves a createRequire/fileURLToPath to the top level, the bug resurfaces.
• The proposed Windows smoke test in CI would catch only the top-level form. To catch latent forms, a unit test that exercises the native-CLI resolver on Windows would help too.
• Workaround for users: downgrading to any 2.1.109 → 2.1.128 restores activation, but if you rely on features that invoke the bundled native CLI, the same TypeError will still surface from the lazy branch.

Thanks for the detailed analysis @alexoDevMX.

Updated workaround: downgrade to 2.1.128 also works and is closer to the latest version.

+1 — confirming this regression on a separate Windows machine.

Environment

• OS: Windows 11 Enterprise 26200
• VS Code: 1.118.1 (x64)
• Claude Code CLI: 2.1.129 (native installer at C:\Users\<user>\.local\bin\claude.exe)
• Extension: anthropic.claude-code-2.1.129-win32-x64

Reproduction

Plugin/skill installs via Claude CLI silently triggered self-update from a previous working version to 2.1.129. After VS Code reload the panel rendered empty (Claude Code tab shows blank webview) and the keybinding popup surfaced command 'claude-vscode.editor.openLast' not found.

Stack trace (exthost.log)

[error] Activating extension Anthropic.claude-code failed due to an error:
[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 Object.<anonymous> (c:\Users\USER\.vscode\extensions\anthropic.claude-code-2.1.129-win32-x64\extension.js:102:5407)

The bundled sdk.mjs reference resolves to the GitHub Actions runner's Linux path (/home/runner/...) which is a valid POSIX absolute path but is rejected by Node on Windows since it neither matches a Windows absolute path nor a file:// URL the runtime accepts. The Linux-flavored string was inlined into the bundle at build time and never substituted on Windows install.

Side effects observed beyond the empty panel

• Repeated activation throw appeared to keep the extension host busy → noticeable typing/response lag in the editor and integrated terminal.
• Stale keybindings referencing the old claude-vscode.* command IDs surfaced "command not found" toasts on Ctrl+Shift+K etc. (cosmetic, not the root cause).

Workaround that fixed it

# Downgrade native CLI to last known-good
claude install stable --force      # landed on 2.1.119

# Pin and prevent the auto-updater from re-bumping to 2.1.129
setx DISABLE_AUTOUPDATER 1

# Manually clean the broken extension bundle (CLI install does NOT replace the
# already-deployed VS Code extension folder)
Remove-Item -Recurse -Force "$env:USERPROFILE\.vscode\extensions\anthropic.claude-code-2.1.129-win32-x64"

# In VS Code: uncheck "Auto Update" on the extension card, Uninstall to clear the
# stale registry entry in extensions.json, then "Install Another Version" → 2.1.119

After reload the panel activates cleanly and editor responsiveness returns to normal.

Suggested fixes

1. Replace the inlined absolute path with a __dirname/import.meta.url based resolver so the value is computed at runtime per-platform, not baked at build time.
2. Add a Windows smoke-test job in CI that installs the produced VSIX into a real code.exe and asserts activate() does not throw — this regression would have been caught.
3. Consider unpublishing 2.1.129 from the latest channel until the hotfix ships, since the auto-updater is silently pulling Windows users into a broken state with no in-app indication.

Happy to share the full exthost.log privately if helpful.

Thanks for the report and very sorry for the disruption. We're getting a fix out for this right now, stand by.

I encountered the same problem on a Windows machine that had never had this extension installed before, so 2.1.129 was the starting point. Oddly enough, Claude recommended downgrading to 2.1.49, referring to a bug that was introduced in extension v2.1.51 where "the extension bundle contains a hardcoded Linux CI build path (file:///home/runner/work/...) baked into extension.js, which is invalid on Windows and causes the extension to fail activation entirely". Obviously, I didn't want to stay 80 versions behind, so I upgraded from 2.1.49 to 2.1.128, and the extension continued to work. (Upgrading again to 2.1.129 broke it again, so I just went back to 2.1.128.)

Thanks for the reports! This should now be resolved in 2.1.131, please update to pick up the fix.

Let us know if you run into any addition problems, thank you for your patience.

This seems to be happening again in version 2.1.136

This seems to be happening again in version 2.1.136

I have same here. Encountered this on version 2.1.136.
Here is my environment for reference:

VSCode Version: 1.119.0 (user setup)
Date: 2026-05-05T11:23:50-07:00
Electron: 39.8.8
ElectronBuildId: 13870025
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

I am getting this issue consistently

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.