Extension v2.1.136 fails to activate on Windows: hardcoded Linux CI path in createRequire()

Extension v2.1.136 fails to activate on Windows — hardcoded Linux CI path leaked into bundle

Summary

The shipped extension.js for anthropic.claude-code@2.1.136 (target win32-x64) calls Module.createRequire() with a hardcoded Linux CI build path, which Node rejects on Windows because the URL has no drive letter. Activation throws synchronously, the extension never loads, and no UI ever appears in VS Code.

The CLI works fine — only the VS Code extension is affected.

Environment

• OS: Windows 11 Home 10.0.26200 (x64)
• VS Code: 1.119.0 (commit 8b640eef5a6c6089c029249d48efa5c99adf7d51, x64)
• Extension: anthropic.claude-code@2.1.136 (target platform win32-x64)
• Claude Code CLI: 2.1.136 (installed via npm, working normally)
• Install source: VS Code Marketplace

Steps to reproduce

1. Install the Claude Code extension on a fresh Windows VS Code install.
2. Open VS Code.
3. Wait for onStartupFinished activation.

Expected behavior

Extension activates; Claude Code panel/icon appears in the sidebar; the IDE integration writes a lockfile to %USERPROFILE%\.claude\ide\.

Actual behavior

Activation throws immediately. No panel appears. No anthropic.claude-code log directory is created under %APPDATA%\Code\logs\<session>\window*\exthost\. The user sees no error in the UI — the extension is silently dead.

Error from exthost.log

[info]  ExtensionService#_doActivateExtension Anthropic.claude-code, startup: false, activationEvent: 'onStartupFinished'
[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 Module.createRequire (node:internal/modules/cjs/loader:1922:13)
    at Object.<anonymous> (c:\Users\Anthony\.vscode\extensions\anthropic.claude-code-2.1.136-win32-x64\extension.js:103:5579)
    at Module._compile (node:internal/modules/cjs/loader:1713:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1847:10)
    at Module.load (node:internal/modules/cjs/loader:1448:32)
    at Module._load (node:internal/modules/cjs/loader:1270:12)

Root cause

The bundled extension.js contains a literal CI-host path captured at build time. Two occurrences in the shipped win32-x64 bundle (lines 103 and 204):

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

This looks like a build-time replacement of import.meta.url (or equivalent) that ran on a GitHub Actions Linux runner (/home/runner/work/...) and got inlined as a constant. On Windows, Node refuses this string in createRequire() because it has no drive letter — it's not a valid Windows file URL and not an absolute Windows path.

The same bundle is shipped to the win32-x64 target, so every Windows user on v2.1.136 should hit this. (We confirmed the issue reproduces; the CLI itself, which is bundled separately, is unaffected.)

Suggested fix

The bundler should anchor createRequire to a path that's resolvable wherever the bundle eventually runs — e.g., __filename at runtime, or a file: URL constructed at runtime from __dirname. Inlining the build-host path is unsafe across platforms.

If the SDK shim genuinely needs a stable anchor for relative resolution, anchor it to the extension's own bundled file (e.g., pathToFileURL(__filename).href) at runtime rather than at build time.

Local workaround (for users hitting this now)

Replace both occurrences of the bad string in the installed extension.js with a valid Windows file URL pointing at the extension's own bundle, then reload VS Code:

$ext = "$env:USERPROFILE\.vscode\extensions\anthropic.claude-code-2.1.136-win32-x64\extension.js"
Copy-Item $ext "$ext.bak"
$bad  = 'file:///home/runner/work/claude-cli-internal/claude-cli-internal/build-agent-sdk/sdk.mjs'
$good = 'file:///c:/Users/<you>/.vscode/extensions/anthropic.claude-code-2.1.136-win32-x64/extension.js'
[IO.File]::WriteAllText($ext, ([IO.File]::ReadAllText($ext)).Replace($bad, $good))

After patching, the extension activates cleanly and the Claude side panel appears.

Severity

High for Windows users — extension is fully unusable on a clean install of v2.1.136. CLI users are unaffected.