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

Resolved 💬 3 comments Opened Mar 26, 2026 by AFN7 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 ↗