Windows auto-update renames bin/claude.exe to .old with no atomic fallback - kills all concurrent sessions (terminals, agents, Cursor) at once (v2.1.162)

Summary

On Windows, the auto-updater renames the single global bin/claude.exe to bin/claude.exe.old.<timestamp> and leaves a window where no claude.exe exists. Because every install (every terminal, every agent, the Cursor integration) shares that one global binary path, the swap takes down all concurrently running sessions simultaneously, and the npm PATH shim then fails for every new launch with CommandNotFoundException.

This is not a one-off — it reproduced within minutes: restore the binary, launch claude, and the update fires again and re-breaks the install.

Environment

• claude-code: 2.1.162
• Install: npm global (C:\Users\sahil\AppData\Roaming\npm\node_modules\@anthropic-ai\claude-code)
• OS: Windows 11 Home, build 26200
• Node: v22.19.0
• npm: 11.6.0
• Shell: Windows PowerShell 5.1

What I observed (verified)

1. claude failed at the PATH shim. claude.ps1 line 14 invokes:

node_modules/@anthropic-ai/claude-code/bin/claude.exe
which did not exist -> CommandNotFoundException.

1. The bin/ directory contained only claude.exe.old.1780606666068 (239,551,648 bytes, mtime 2026-06-04 16:51:52) and no claude.exe.
2. Restoring it (rename claude.exe.old.1780606666068 -> claude.exe) fixed it: claude --version returned 2.1.162 (verified twice, via full path and via the PATH shim).
3. A fresh terminal then ran claude and hit the same CommandNotFoundException again.
4. On re-check, bin/claude.exe was present again with the same mtime (16:51:52) as the restored file — i.e. the binary momentarily disappeared and reappeared, confirming a swap window during which bin/claude.exe does not exist.

Inferred root cause

The updater performs an in-place swap of the single shared global binary: rename current -> .old.<timestamp>, then write the new binary. There is a window where bin/claude.exe is absent. Any process that launches claude during that window fails. When the write step is interrupted or never completes, the install is left permanently broken (only the .old file remains). Two structural problems:

• No atomicity / no rollback: a failed/interrupted write leaves the install with no usable claude.exe instead of falling back to the previous one.
• Single shared global binary = single point of failure: the swap is global, so it does not just affect the session that triggered the update — it kills every other running terminal, agent, and IDE integration pointed at the same binary, all at once.

(The exact internal swap sequence is inferred from the observed file states above; the file-state observations themselves are verified.)

Impact

A single botched auto-update simultaneously took down, in one event:

• ~5 terminals
• ~10 running agents
• Work spread across ~4 monitors
• The Cursor IDE (its Claude Code integration)

Alongside this, the machine hit severe memory exhaustion: RAM at 60.3 GB / 64 GB with ~103 GB of paging. This is plausibly both a trigger and a consequence: under that memory pressure the OS may have killed the updater mid-write (leaving the install with only the .old binary), and the cascade of sessions/agents each reloading a ~240 MB binary plus restarting would in turn drive memory and page-file usage up. Either way, a 240 MB single-file binary swapped in-place across many concurrent sessions is a heavy footprint.

This is severe: an in-place update of a shared binary should never be able to terminate unrelated concurrent sessions, and a failed update should never leave the install with no runnable binary.

Reproduction

1. Have multiple claude sessions / agents running (multiple terminals, plus Cursor).
2. Trigger / allow an auto-update.
3. During the rename-then-write swap, concurrent sessions die and new claude launches fail with CommandNotFoundException pointing at the missing bin/claude.exe.
4. If the write step does not complete, only bin/claude.exe.old.<timestamp> remains and the install stays broken until manually restored.

Workaround

Rename bin/claude.exe.old.<timestamp> back to bin/claude.exe, or reinstall with npm i -g @anthropic-ai/claude-code. Setting DISABLE_AUTOUPDATER=1 and updating manually avoids the swap entirely.

Suggested fixes

1. Atomic swap with rollback: write the new binary to a temp name, then atomically replace; on any failure, keep/restore the previous binary so the install is never left with no claude.exe.
2. Don't disrupt running sessions: a running process should keep using its already-loaded binary; never rename the on-disk binary out from under live sessions in a way that can crash them.
3. Stage updates, apply on next launch: download to a side path and switch the shim atomically, rather than mutating the in-use path.
4. Self-heal: if bin/claude.exe is missing but a bin/claude.exe.old.* exists, restore it automatically instead of failing.