[BUG] Session silently stopped persisting to JSONL for 10 days while still working; resume after auto-update loads the stale state (Windows variant of #79298)

Same signature family as #79298 (filed 2026-07-20, Linux) and the closed-as-duplicate #22566 ("assistant responses silently stop persisting to session JSONL"). Filing the Windows data point separately with forensics, since #79298's author asked for more cases to localize the trigger.

Symptom

A long-lived interactive session (my main "brain" session, ~50% of Fable 5's 1M context) silently stopped writing to its ~/.claude/projects/<dir>/<id>.jsonl on Jul 9. The session kept working normally in the terminal for 10 more days (Jul 14, 16, 17–19 — heavy daily use). On Jul 20 I ran claude update (required to access Fable 5 after it moved to usage credits) and then claude --resume <id> — the conversation loaded at the Jul 9 state (~10% context). Ten days of conversation are unrecoverable from disk.

Forensics

• The JSONL ends cleanly at Jul 9 12:41 (a turn_duration + away_summary entry, version 2.1.200 on the entries). Per-day entry counts: Jul 4 (456), Jul 5 (77), Jul 6 (36), Jul 8 (23), Jul 9 (14), then nothing — zero user/assistant records for Jul 14–19.
• Independent proof the session ran during the frozen window: a PreToolUse hook on my machine logs every tool call keyed by session id. That log (session-<id8>.log) shows SESSION START markers for the same session id on Jul 14 12:17, Jul 16 11:54, Jul 17 15:00, with ~560 logged tool calls across those blocks — file writes and git commits that all exist on disk/in git history today. So the session was fully alive; only transcript persistence had died.
• ~/.claude/history.jsonl is missing the same window: it holds 16 prompts for this session, the last dated Jul 9 — none of the Jul 14–19 prompts were recorded either (matches #79298's observation exactly).
• Sidecar metadata survived: custom-title, last-prompt, mode records are present and current — the file's mtime updates on open, but no message records are appended.
• The live resumed session also doesn't persist observably: while writing this report from the resumed session, none of today's user/assistant turns can be found in any projects/*.jsonl (grep for verbatim message text across the whole projects dir = 0 hits), suggesting transcript writes are buffered/deferred far longer than a turn, or going nowhere.
• cd-heavy usage matches #22566's trigger hypothesis: the session routinely cd'd across 4+ repos and used /add-dir. It was also compacted once (Jul 6) before the freeze — freeze point is 3 days after the compact.

Timeline

| Date | Event |
|---|---|
| Jul 3–4 | Session created (v2.1.200 era), heavy use |
| Jul 6 | /compact; use continues |
| Jul 9 12:41 | Last entry ever written to the JSONL |
| Jul 14 / 16 / 17–19 | Session used heavily in the same terminal tab (proven via hook log + git commits); nothing persisted |
| Jul 20 ~09:50 | claude update → 2.1.208 (needed for Fable-on-credits), then claude --resume <id> → conversation loads at the Jul 9 state |

Environment

• Windows 11 Home 10.0.26200, Git Bash tabs inside Windows Terminal
• Claude Code 2.1.200 → 2.1.208 (claude update on Jul 20; auto-updates in between possible)
• Max subscription; model Fable 5, effort high; ~50% of 1M context at loss time
• Session spawned subagents and background tasks during the frozen window

Impact

10 days of conversation text gone (the work products survived only because the session committed files to git as it went). A second machine-independent report the same week (#79298: 27 sessions) suggests this is hitting long-lived, multi-directory, subagent-heavy sessions specifically — i.e., exactly the sessions users care most about.

Happy to provide the sanitized JSONL tail, the hook log, and per-day entry counts, or run instrumented repros.