[BUG] 2.1.237 tagged `latest` with its linux-x64, win32-x64 and linux-x64-musl native packages never published - installs land on a dead 500-byte stub

Yep, 2.1.237 broke claude for me under WSL2/Arch as well.

Following up with something that makes this worse than a one-off bad install: the background auto-updater reinstalls the broken version on its own, so repairing it does not stick.

Timeline on my machine (Windows 11 x64, npm-global under a conda prefix):

22:09:44   repaired by hand: npm i -g @anthropic-ai/claude-code@2.1.236
           bin\claude.exe = 330,097,824 bytes, claude --version -> 2.1.236   OK
22:19:28   auto-updater pulls 2.1.237 unprompted
           bin\claude.exe = 500 bytes, package.json -> 2.1.237               DEAD AGAIN

Ten minutes. No user action in between. So for anyone on win32-x64, linux-x64 or linux-x64-musl right now, this is not "install latest and get a broken CLI once" — it is a loop. You repair it, and the updater walks it back into the stub on its next check. Pinning to 2.1.236 is not sufficient on its own, because nothing in the install expresses the pin to the updater.

Workaround, for anyone hitting this before it is fixed upstream

Set the kill switch first, then repair — otherwise the repair is on a timer:

// ~/.claude/settings.json
{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

npm i -g --allow-scripts=@anthropic-ai/claude-code @anthropic-ai/claude-code@2.1.236

I verified the variable is actually read by the binary before trusting it — findstr /M /C:"DISABLE_AUTOUPDATER" against the 326 MB claude.exe hits, as do autoUpdates and autoUpdaterStatus. Setting a variable the binary ignores would look exactly like a working fix until the next update landed.

⚠️ It applies per session, at startup. Sessions already running when you set it keep their own updater and can still re-break the install. Restart every live session, or the loop continues from the old ones. I had four alive and this cost me a second repair.

Remove the variable once the missing native packages are published.

Two things from the repair that may be useful for the fix itself

1. install.cjs can exit 0 having produced a version-mismatched install. After one retry it left me with package.json reporting 2.1.237 while claude --version reported 2.1.236. The native package was not in the tree at all; install.cjs had fallen back to the local bin\claude.exe.old.<timestamp> left by the previous update's rename. The CLI runs, so nothing looks wrong, but the wrapper and the binary disagree about what is installed. A clean reinstall of 2.1.236 brought both into line. This is a second silent-success path in the same script, alongside the missing-native one — checking --version alone does not detect it.

2. EBUSY on placing the binary can be transient. One attempt died with EBUSY: resource busy or locked, unlink 'bin\claude.exe'. A lock probe seconds later returned free, and no process was executing that path — the live sessions run the renamed copy, not the stub. A retry succeeded on the first try. Worth a short retry loop in install.cjs rather than surfacing it as a hard failure, since on Windows this is most likely a scanner or the just-finished write rather than a real holder.

Both of these reinforce the original ask: install.cjs exiting non-zero when it cannot place the correct binary would turn all of these into a loud failure instead of a working-looking install.

The workaround (npm i -g @anthropic-ai/claude-code@2.1.236) works, but most users hitting this won't know to look for it — they'll just conclude Claude Code is broken on their platform.

confirmed on NixOS (glibc x86_64) with mise/aube as npm backend.

aube add --global @anthropic-ai/claude-code@2.1.237 fails because @anthropic-ai/claude-code-linux-x64@2.1.237 does not resolve. npm with --omit=optional installs but leaves the 500-byte stub, so claude is non-functional.

of the eight optionalDependencies declared at 2.1.237, only these four exist (as issue author stated):

• @anthropic-ai/claude-code-darwin-x64 2.1.237
• @anthropic-ai/claude-code-darwin-arm64 2.1.237
• @anthropic-ai/claude-code-linux-arm64 2.1.237
• @anthropic-ai/claude-code-win32-arm64 2.1.237

these three are 404:

• @anthropic-ai/claude-code-linux-x64 2.1.237
• @anthropic-ai/claude-code-linux-x64-musl 2.1.237
• @anthropic-ai/claude-code-win32-x64 2.1.237

as my (and 95% of the world) machine(s) needs linux-x64, which is missing, claude errors/freezes, was only easy to debug due to experience with mise/nix/aube/npm. pinning to 2.1.236 works as stated

Same issue on Windows 11 Enterprise 26200 x64, node v26.5.0. Auto-updated from 2.1.236 to 2.1.237. Confirmed win32-x64 native is E404 on registry. Workaround npm i -g @anthropic-ai/claude-code@2.1.236 fixed it. Please publish the missing native or move latest back to 236.

Linux x64 data point, and a correction to the "safe with sessions open" note.

1. The downgrade does not hold on npm-global Linux installs.

npm i -g @anthropic-ai/claude-code@2.1.236 restores a working CLI, but the background updater re-applies 2.1.237 on the next launch and the install returns to the stub. Repaired it twice, broke twice. The workaround needs DISABLE_AUTOUPDATER=1 in ~/.claude/settings.json (or autoUpdatesChannel: "stable") set before the reinstall, otherwise the pin is silently undone.

2. On Linux, the in-place update is not safe with sessions open.

The note about npm renaming the old tree so running sessions keep working did not hold here. The update was applied mid-run to a background session, after which the background service could no longer be spawned:

Couldn't reach the background service (spawn background service: ENOEXEC:
unknown error, posix_spawn '<npm-global-prefix>/lib/node_modules/@an...')

The session still appeared in claude agents but selecting it did nothing — it was unreachable. Roughly three hours of work was lost. The workflow ran under a custom skill that only produces usable output on completion, so the partial artifacts on disk were worthless.

That makes this more than a broken install: on the latest channel the updater will keep pulling 2.1.237 into working installations and killing whatever is running at the time. Possibly overlapping with #88091.

Note this is npm 10.9.8 / node 22, a different generation from the report above (npm 11 / node 26) — the missing artifact breaks the install regardless of npm version, as expected for a package that simply is not on the registry.

Env: Ubuntu 26.04 LTS, Linux x64, node v22.23.1, npm 10.9.8, npm global prefix under $HOME, auto-updated from 2.1.235.

+1. Confirming this on Windows 11 x64. My auto-update ran this morning and the same thing happened. Here's the full evidence chain from my machine, in case it helps:

Environment

• OS: Windows 11 Pro 22H2, x64
• Install: npm global (npm i -g @anthropic-ai/claude-code)
• Auto-updated from 2.1.236 → 2.1.237 on 2026-08-20T01:58:27Z (UTC)

Symptom

After the auto-update, claude in a fresh terminal fails immediately:

> claude --version
"The specified program is not a valid Win32 application" (exit code 1)

bin/claude.exe in the global install is a 500-byte placeholder stub (the echo "Error: claude native binary not installed..." script), not a real PE binary. The platform package @anthropic-ai/claude-code-win32-x64 is absent from node_modules/@anthropic-ai/.

The only session still alive is the one that was launched 14 seconds before the update finished (PID started 01:58:13Z, update completed 01:58:27Z) — its 2.1.236 binary is memory-mapped, so it keeps running. Any new session cannot be started at all until this is fixed.