Windows: auto-updater reports success while claude.exe is locked (version never switches); session transcripts silently never written / stop being written (permanent data loss)

Windows: auto-updater reports success while claude.exe is file-locked and never switches versions; sessions silently stop persisting transcripts (unresumable, permanent data loss)

Environment

• Claude Code: 2.1.200 active (2.1.201 downloaded but never activated — see Bug A); versions 2.1.198 → 2.1.201 installed over the last 3 days via auto-update, autoUpdatesChannel: "latest"
• Install: native installer, C:\Users\<user>\.local\bin\claude.exe (launcher) + C:\Users\<user>\.local\share\claude\versions\<version> (binaries)
• OS: Windows 11 Pro 10.0.26200
• Terminals affected: both a plain pwsh terminal session and sessions running inside a node-pty (ConPTY) wrapper — the wrapper is not a factor
• Settings: tui: fullscreen, defaultMode: bypassPermissions; sessions launched with --dangerously-skip-permissions --effort high, some with --resume

Two distinct but related bugs, both verified with the NTFS USN change journal (full coverage of the incident window on drive C:), file timestamps, and a live reproduction.

---

Bug A — auto-updater claims success but never activates the new version (file lock silently ignored)

claude update (and the background auto-update) reports success, but the launcher claude.exe is never replaced while any Claude Code process is running, so the active version never changes. No error is surfaced.

Live reproduction (2026-07-04 ~11:40 UTC+8), with one interactive claude.exe process running:

> claude update
Current version: 2.1.200
Checking for updates to latest version...
Updating to 2.1.201...
Successfully updated from 2.1.200 to version 2.1.201

> claude --version
2.1.200 (Claude Code)

• C:\Users\<user>\.local\bin\claude.exe mtime is unchanged (2026-07-04 00:53, i.e. the 2.1.200 install), even though versions\2.1.201 was downloaded at 07:52:55.
• .claude\.last-update-result.json records {"outcome":"success","version_from":"2.1.200","version_to":"2.1.201"} — a false success.
• Direct file-lock check while one interactive session is running:

[System.IO.File]::Open('...claude.exe','Open','Write','None') → "The process cannot access the file ... because it is being used by another process."

So: running claude.exe → launcher write-locked → updater cannot swap it → reports success anyway. This looks adjacent to #61676 / #51954, but here the lock holder is Claude Code itself (any running interactive session), no VS Code involved.

---

Bug B — session transcripts silently never written / stop being written; sessions become unresumable

During the same window, session persistence failed in two modes. All evidence below is from the NTFS USN change journal on C:, which fully covers 08:16–10:46 local time (UTC+8) on 2026-07-04.

Mode 1 — transcript never created at all. Two interactive sessions this morning (session IDs 9a363718-…, started 07:53, ended 08:57; and 33867b00-…, started 09:28, active until ~10:35) did substantial work: they spawned subagents, edited files, ran tools, made git commits. For both sessions:

• ~/.claude/projects/<project>/<sessionId>.jsonl does not exist, and the USN journal contains zero create/write records for those filenames during the entire covered window while the sessions were demonstrably active (subagent *.meta.json written 10:09–10:11, file-history snapshots written 09:37–10:34, tool-results written up to 08:57).
• Everything around the transcript persisted normally: ~/.claude/projects/<project>/<sessionId>/subagents/*.meta.json, <sessionId>/tool-results/*.txt, ~/.claude/file-history/<sessionId>/*, MCP logs under AppData\Local\claude-cli-nodejs\Cache\..., .claude.json backups. Only the main transcript .jsonl (and history.jsonl, below) are missing.
• Net result: orphan session directories — projects/<project>/<sessionId>/subagents/ exists, projects/<project>/<sessionId>.jsonl does not. The sessions do not appear in --resume and their content is permanently lost (nothing to recover; the data was never written).

Timing note: versions\2.1.201 finished downloading at 07:52:55, and the first never-persisted session started at 07:53 — the session launched exactly as the update was being installed.

Mode 2 — persistence dies mid-session right after an auto-update completes. A session started at 10:44:20 in a plain pwsh terminal persisted normally at first (USN shows continuous appends to its <sessionId>.jsonl, 10:44:20–10:46:15, 183 KB). The background auto-update completed at 10:45:36 (.last-update-result.json timestamp). About 40 seconds later the transcript received its last write ever (10:46:15). The session kept running for over an hour, doing heavy tool work — zero further writes to its transcript. No error, no warning.

Global history stopped too. ~/.claude/history.jsonl received its last append at 10:44:19. All user prompts typed after that, in any session, were never recorded.

What kept working the whole time (same processes, same directories): file-history snapshots, subagent meta files, tool-results, MCP logs, .claude.json backups, memory-file edits via tools. So this is not a permissions/disk problem — the transcript/history writer specifically dies (or never initializes), everything else keeps writing.

Ruled out (this is why we're confident it's never-written, not deleted-after):

• USN journal shows no delete or rename records for those transcript filenames in the covered window; there are simply no records at all.
• Recycle Bin empty of .jsonl; full-disk search for the session IDs and for unique content strings from the lost conversations found nothing.
• No hooks or scripts on this machine delete transcripts; retention cleanup (.last-cleanup) ran after the loss was already observed and the files are same-day anyway.

---

Impact

• Hours-long working sessions are silently unresumable; users only find out when --resume doesn't show them.
• Because the failure is silent and everything else (commits, side files) keeps working, users have no signal that their conversation is not being saved.
• The updater false-success means users believe they're patched when they're not, and (if the update swap is what kills the writer) every auto-update becomes a data-loss event for running sessions.

Suggested repro

1. Windows, native install, start one interactive Claude Code session and leave it running.
2. Trigger claude update when a new version is available → observe "Successfully updated" while claude --version and the launcher mtime are unchanged.
3. While a session is running when the auto-update completes, watch ~/.claude/projects/<project>/<sessionId>.jsonl mtime — appends stop shortly after the update, while the session keeps working.

Workaround we're using

• Treat conversations as volatile: flush important conclusions to files/commits immediately.
• Periodically check the transcript mtime is advancing; if it stops, wrap up and restart the session.
• Close all Claude Code processes before updating; verify with claude --version afterwards.

Happy to provide the USN journal extracts, timestamps, or run additional diagnostics on this machine.