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:
For comparison, the rolled-back 2.1.154 binary on the same system returns:
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.
Summary
Today's Claude Code auto-update on Windows replaced
claude.exewith a binary that boots into Bun's general CLI help instead of launching Claude Code. The file's embedded version metadata still readsClaude Code 2.1.156.0, but at runtimeclaude --versionreturns1.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
C:\Users\<<USER_HOME>>\.local\bin\claude.exe2.1.1542.1.1562.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
claudewith no args prints Bun's default help text:claude --versionreturns the Bun runtime version, not Claude Code's:For comparison, the rolled-back
2.1.154binary on the same system returns:Smoking gun — file metadata lies about runtime behavior
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.154binary that the auto-updater itself installed earlier the same day: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
Workaround / rollback
The auto-updater leaves the previous binary in place as
claude.exe.old.<unix-ms>. Rolling back is a rename + copy:(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
2.1.156such that the Bun runtime never executes it and falls through to its own argument parser?Happy to provide the broken binary or capture an
strace-equivalent (Procmonlog) if useful.