[BUG] Auto-update wrote a corrupted claude.exe (same size, different SHA256) - instant 0xC0000005, claude update cannot self-recover (Windows native installer)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet (related but distinct: #85729, #80628, #69590 are runtime/loader access violations with healthy binaries; this report is about the updater producing a corrupted binary on disk)
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code (2.1.229)
What's Wrong?
The background auto-update to 2.1.229 (native Windows installer) left a corrupted binary at %USERPROFILE%\.local\bin\claude.exe. The corrupted copy has exactly the same size as the healthy source file in the versions store, but a different SHA256:
| File | Size | SHA256 | Behavior |
|---|---|---|---|
| %USERPROFILE%\.local\bin\claude.exe (installed copy) | 307,186,848 | D358F480EF07CECDC26E8C63616215613D0DE955508141771150D315E881CEAC | instant crash 0xC0000005 |
| %USERPROFILE%\.local\share\claude\versions\2.1.229 (source) | 307,186,848 | 5736C66BE98A372D5E5E3B3598EAD89AB5A9D1ACA60D347FE7B561801C58376C | runs fine when copied elsewhere and executed |
Every invocation of the corrupted exe crashes with STATUS_ACCESS_VIOLATION (exit code -1073741819 / 0xC0000005) before printing anything, so claude, claude --version and claude update all appear to silently do nothing. Because claude update runs through the same broken binary, self-update cannot recover - a chicken-and-egg situation the user can only fix manually.
versions\2.1.228 also runs fine, so only the copy step to .local\bin went wrong.
Timeline
File mtimes plus %USERPROFILE%\.claude\daemon.log (UTC):
20:55:39 [supervisor] daemon start version=2.1.228 pid=2356 origin=transient
20:55:41 (file mtimes) updater wrote versions\2.1.229 AND copied it over .local\bin\claude.exe
20:56:39 [supervisor] binary at %USERPROFILE%\.local\bin\claude.exe changed (mtime changed) - self-restarting for upgrade
20:56:39 [supervisor] shutting down (cause=upgrade, uptime=60s, leases=0, live_workers=1)
20:57:45 [supervisor] upgrade self-respawn spawned but never became reachable within 45s
Possibly relevant context: this is a corporate machine with Microsoft Defender Exploit Guard / ASR rules in audit mode. Defender logged dozens of audit events (event 1122, rule IDs D1E49AAC-8F56-4280-B9BA-993A6D77406C and 01443614-CD74-433A-B99E-2ECDC07BFC25) with Path: ...\.local\bin\claude.exe in the exact seconds of the update (20:55:38-20:57:00 UTC). A daemon was also live and self-respawning from the very same path while it was being replaced. So the in-place copy of a ~300 MB exe raced with both AV filter-driver interception and processes (re)spawning from that path. Same size + different content smells like a partially flushed / dirty in-place overwrite.
What Should Happen?
- The updater should replace the launcher binary atomically: write to a temp file in the same directory, then rename over the target - never copy in place over a path that live daemons/sessions execute from.
- After installing, verify the hash of the installed copy (the healthy artifact sits right there in the versions store to compare against) and retry or roll back on mismatch. A same-size-different-content corruption is invisible to any size check.
- This failure mode is currently unrecoverable via
claude updatebecause the updater itself is the corrupted binary. A minimal fallback (e.g. installer re-run instruction printed by a crash handler, or a tiny launcher that falls back to the newest healthy version in the versions store) would make it self-healing.
Error Messages/Logs
PS> claude --version
PS> $LASTEXITCODE
-1073741819 # 0xC0000005 STATUS_ACCESS_VIOLATION, no output at all
Workaround (confirmed fix)
Copy-Item "$env:USERPROFILE\.local\share\claude\versions\2.1.229" "$env:USERPROFILE\.local\bin\claude.exe" -Force
Hashes match after the copy and 2.1.229 works normally again.
Environment
- Claude Code 2.1.229, native Windows installer (not npm)
- Windows 11 Enterprise 10.0.26200, x64
- Corporate Microsoft Defender with ASR rules in audit mode
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗