Claude Code VS Code extension v2.1.83 crashes on WSL1 - native binary Exec format error

Status Closed — duplicate
Reported on v2.1.83
Maintainer reply None cached
Activity 3 comments · opened Mar 26, 2026 · closed Mar 26, 2026

Description

Claude Code VS Code extension v2.1.83 fails to start on WSL1. The native binary cannot be executed, causing the extension to crash immediately.

Environment

  • OS: Windows 10/11 with WSL1 (not WSL2)
  • Kernel: 4.4.0-26100-Microsoft
  • Extension version: 2.1.83 (broken), 2.1.81 (works)
  • VS Code: Remote - WSL

Error

From the extension output log:

/home/user/.vscode-server/extensions/anthropic.claude-code-2.1.83-linux-x64/resources/native-binary/claude: 1: ELF: not found
/home/user/.vscode-server/extensions/anthropic.claude-code-2.1.83-linux-x64/resources/native-binary/claude: 2: Syntax error: ")" unexpected

Running the binary directly:

$ file .../native-binary/claude
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked...

$ .../native-binary/claude --version
/bin/bash: .../native-binary/claude: cannot execute binary file: Exec format error

Root Cause

WSL1 uses a translated syscall layer (kernel 4.4.0) that cannot execute certain ELF binaries. The shell falls back to interpreting the binary as a script, producing the ELF: not found error.

v2.1.81 worked fine — the regression was introduced in v2.1.83 which appears to rely on this native binary.

Workaround

Downgrading to v2.1.81 resolves the issue. Auto-update must be disabled to prevent re-upgrading.

Expected Behavior

The extension should fall back to a Node.js-based execution path when the native binary is not executable (as it did in v2.1.81), or detect WSL1 and skip the native binary.

Suggestion

  • Add a runtime check: attempt to execute the native binary, and fall back to Node.js if it fails
  • Or detect WSL1 via uname -r (contains Microsoft but not microsoft-standard which is WSL2)

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗