[Bug] Claude Code crashes on WSL when Windows interop is disabled — unguarded reg.exe spawn (ENOEXEC)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment

• Host: Windows with WSL2, interop intentionally disabled (/etc/wsl.conf [interop] enabled=false) for security

hardening on a build box

• WSL distro: Ubuntu on x64
• Claude Code versions tested: 2.1.118 (latest), 2.1.108 (stable) — both crash
• Bun: v1.3.13 (Linux x64 baseline)
• Install method: native installer (curl ... install.sh)

Summary
Claude Code unconditionally spawns /mnt/c/Windows/System32/reg.exe on startup. On WSL distros where Windows interop
is disabled, that path exists on the /mnt/c mount but cannot be executed (binfmt_misc WSLInterop not registered),
so posix_spawn returns ENOEXEC and the process crashes before a prompt is shown. The crash also fires inside
install.sh when it invokes the freshly-downloaded binary for setup, which makes rollback via the installer impossible.

Repro

1. WSL2 distro with /etc/wsl.conf containing [interop]\nenabled=false, wsl --shutdown, reopen.
2. Confirm interop is off: /mnt/c/Windows/System32/cmd.exe /c ver fails with ENOEXEC.
3. curl -fsSL https://claude.ai/install.sh | bash -s stable → crashes during "Setting up Claude Code...".
4. Any attempt to launch claude also crashes with the same stack.

Stack trace
ENOEXEC: unknown error, posix_spawn '/mnt/c/Windows/System32/reg.exe'
path: "/mnt/c/Windows/System32/reg.exe"
syscall: "posix_spawn"
errno: -8
code: "ENOEXEC"

at spawn (node:child_process:667:35)
at execFile (node:child_process:59:20)
at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:188:1452)
at gl6 (/$bunfs/root/src/entrypoints/cli.js:188:1422)
at $W$ (/$bunfs/root/src/entrypoints/cli.js:188:1822)
at Ql6 (/$bunfs/root/src/entrypoints/cli.js:188:1861)

Bun v1.3.13 (Linux x64 baseline)

Expected
reg.exe (presumably Chrome native-messaging host registration, ref #41625) should be gated behind a runtime check
for working WSL interop — e.g. probe /proc/sys/fs/binfmt_misc/WSLInterop for enabled, or wrap the spawn in
try/catch and log-and-skip on ENOEXEC/ENOENT. It should not be on the critical startup path, and it should not fail the installer.

Workaround
On affected boxes: avoid the native installer; install via npm at a version that predates the feature (users should not have to bisect to find it — documenting the introducing version would help).

Severity
Blocks all Claude Code use on security-hardened WSL build/CI environments.

What Should Happen?

Claude should be able to start up as usual

Error Messages/Logs

ENOEXEC: unknown error, posix_spawn '/mnt/c/Windows/System32/reg.exe'
    path: "/mnt/c/Windows/System32/reg.exe",
 syscall: "posix_spawn",
   errno: -8,
    code: "ENOEXEC"

      at spawn (node:child_process:667:35)
      at spawn (node:child_process:14:39)
      at execFile (node:child_process:59:20)
      at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:188:1452)
      at new Promise (1:11)
      at gl6 (/$bunfs/root/src/entrypoints/cli.js:188:1422)
      at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:188:1602)
      at $W$ (/$bunfs/root/src/entrypoints/cli.js:188:1822)
      at Ql6 (/$bunfs/root/src/entrypoints/cli.js:188:1861)

Steps to Reproduce

Have the latest version of Claude 2.1.118 and be using WSL with interop turned off

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.118

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_