claude-code - 💡(How to fix) Fix Auto-update on Windows shipped a binary that boots into Bun's CLI instead of Claude Code (2.1.154 -> 2.1.156)

Summary

Today's Claude Code auto-update on Windows replaced claude.exe with a binary that boots into Bun's general CLI help instead of launching Claude Code. The file's embedded version metadata still reads Claude Code 2.1.156.0, but at runtime claude --version returns 1.3.14 — the Bun runtime version. Fresh terminals are unusable until the binary is rolled back; in-progress Claude Code sessions are unaffected because their file handle is independent of the new file on disk.

Environment

• OS: Windows 11 Enterprise 10.0.26200
• Shell: PowerShell 7
• Install location: C:\Users\<<USER_HOME>>\.local\bin\claude.exe
• Previous working version: 2.1.154
• Broken version (per file metadata): 2.1.156
• Auto-update sequence on 2026-05-28: 2.1.153 (5/27 8:52 PM) → 2.1.154 (5/28 2:19 PM) → 2.1.156 (5/28 5:21 PM, broken). Both prior .old.* backups verify clean.

Symptoms

claude with no args prints Bun's default help text:

Bun is a fast JavaScript runtime, package manager, bundler, and test runner. (1.3.14+521eedd6d)

Usage: bun <command> [...flags] [...args]

Commands:
  run       ./my-script.ts       Execute a file with Bun
            lint                 Run a package.json script
  test                           Run unit tests with Bun
...

claude --version returns the Bun runtime version, not Claude Code's:

1.3.14

For comparison, the rolled-back 2.1.154 binary on the same system returns:

2.1.154 (Claude Code)

Smoking gun — file metadata lies about runtime behavior

Path:            C:\Users\<<USER_HOME>>\.local\bin\claude.exe.broken-2.1.156
Length:          236074144 bytes
LastWriteTime:   2026-05-28T17:21:08
ProductName:     Claude Code
FileVersion:     2.1.156.0
ProductVersion:  2.1.156.0
InternalName:    bun
CompanyName:     Anthropic PBC
SHA256:          2DC2B5868709B1458D138D5C8720DD4D3D112B07F0E19802A080FE35BC1D010B

The PE metadata says Claude Code 2.1.156. The runtime acts like Bun 1.3.14. So the download itself was likely not truncated — something about the packaging or the embedded launcher script is wrong.

For comparison, the working 2.1.154 binary that the auto-updater itself installed earlier the same day:

Length:          236073120 bytes
FileVersion:     2.1.154.0
SHA256:          0A4FD0248444C6F33D659C555DCF66C2AB4A1B2C6AE8C4126C7ECF11C547791A

Sizes are within 1 KB of each other, so this doesn't look like a truncated download. Different SHA-256, as expected.

Diagnosis steps that ruled out other causes

# Only one claude on PATH — no shim or alias shadowing
Get-Command claude -All | Select-Object Name, Source, Version
# -> claude.exe  Application  C:\Users\<<USER_HOME>>\.local\bin\claude.exe  2.1.156.0

# No bun.exe on PATH, no BUN_* env vars
Get-Command bun -All -ErrorAction SilentlyContinue   # empty
Get-ChildItem env: | Where-Object Name -like 'BUN_*' # empty

# No PowerShell alias / function / profile entry for "claude"
Get-Alias claude -ErrorAction SilentlyContinue       # empty

Workaround / rollback

The auto-updater leaves the previous binary in place as claude.exe.old.<unix-ms>. Rolling back is a rename + copy:

$dir = "C:\Users\<<USER_HOME>>\.local\bin"
$candidate = Get-ChildItem $dir -Filter 'claude.exe.old.*' |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 1

# Sanity-check the candidate
$test = "$env:TEMP\claude-test.exe"
Copy-Item $candidate.FullName $test -Force
& $test --version    # expect "2.1.x (Claude Code)"
Remove-Item $test

# Preserve the broken binary, promote the backup
Rename-Item "$dir\claude.exe" "claude.exe.broken-2.1.156"
Copy-Item $candidate.FullName "$dir\claude.exe"
& "$dir\claude.exe" --version   # confirm

(The currently-running Claude Code session is unaffected during the swap because its file handle is independent. Windows allows renaming a running .exe.)

Suspected cause / questions

• Is the embedded Claude launcher script bundled differently in 2.1.156 such that the Bun runtime never executes it and falls through to its own argument parser?
• Is there a signature / integrity check that's silently failing and causing the launcher to no-op?
• Is the auto-updater verifying the new binary before swapping it in? If not, this would be the second-line fix.

Happy to provide the broken binary or capture an strace-equivalent (Procmon log) if useful.