Resumed sessions silently stop writing to session JSONL after claude.exe version upgrade

Summary

After claude.exe is upgraded to a newer version, resuming a session that was last written by an older version causes the session JSONL writer to silently fail. The process appears to run normally — accepting input, generating responses, writing to global ~/.claude/history.jsonl — but conversation entries are NOT appended to the per-session JSONL file (~/.claude/projects/<project>/<session-id>.jsonl). Only metadata entries (permission-mode) are written.

Symptoms

• User resumes a session via claude --resume <session-id>
• Session continues normally from user's perspective
• All input goes to history.jsonl correctly
• But session JSONL stops accumulating new conversation messages
• File modification timestamp updates (because permission-mode entries are appended) but file contents only show metadata
• The "broken state" persists across resume attempts of the same process
• Killing the process and starting a fresh claude --resume <id> recovers normal writing behavior

Affected Environment

• OS: Windows 11 (10.0.26200.8246)
• Shell: Git Bash (MSYS) and cmd.exe both observed
• Claude Code version: observed across 2.1.104 through 2.1.119
• Triggered by: Claude Code auto-updates between session uses

Reproduction (best inference from data)

1. Start a Claude Code session with version N (e.g., 2.1.112)
2. Use it normally; the session writes to <id>.jsonl
3. Stop using the session (let it go idle / leave terminal alone)
4. Wait for claude.exe to auto-update to version N+k
5. Resume the session: claude --resume <id>
6. Type a message: response is generated, but no new lines are appended to <id>.jsonl (except permission-mode metadata)

Evidence Pattern

Examined 5 broken sessions on a Windows system. Each session's JSONL ends with the last message at version N, followed only by permission-mode entries (with no version field, no timestamp). Last good versions across sessions: 2.1.104, 2.1.107, 2.1.112 (twice), 2.1.118. Each session broke at a different date over a 9-day span (4/14–4/23).

A working session that was used continuously across versions 2.1.92 → 2.1.118 did NOT break, suggesting the trigger requires the session to be idle during the version transition.

When the broken session's process is killed and claude --resume <same-id> is run fresh, JSONL writing resumes normally with the new version. So the JSONL file itself is not corrupted — the in-memory writer state of the resumed process is.

Impact

Conversation history is silently lost. Users believe their sessions are being preserved (process accepts input, generates responses) but actually no record is being written to disk. This causes loss of significant context when sessions are eventually restarted.

Possible Root Cause Hypothesis

The resume code path may not properly initialize the JSONL writer when the loaded JSONL was written by an older version. Likely a silent error or no-op in writer setup that doesn't surface to user-visible behavior.