[BUG] Auto-update wrote a corrupted claude.exe (same size, different SHA256) - instant 0xC0000005, claude update cannot self-recover (Windows native installer)

Status Open
Reported on v2.1.229
Maintainer reply None cached
Activity 1 comment · opened Aug 13, 2026

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?

  1. 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.
  2. 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.
  3. This failure mode is currently unrecoverable via claude update because 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

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗