[BUG] In-session /logout silently stops all session persistence (transcript, history, registration) - conversation continues normally, 12h of transcript lost

Summary

Running /logout (then re-authenticating) inside a long-running interactive session
put the session into a "no persistence" state: the conversation continued to work
perfectly (chat, tools, everything), but from that exact moment:

• No new user/assistant entries were appended to the session JSONL

(~/.claude/projects/<project>/<session-id>.jsonl)

• No new entries for this project were appended to ~/.claude/history.jsonl
• The JSONL file's mtime kept updating (metadata-only touches), which makes the

loss invisible — the file looks "recently active"

We only discovered this ~12 hours later. /export from the still-open session was
the only way to recover the conversation.

Evidence timeline (from disk forensics)

| Time (local) | Event | Source |
|---|---|---|
| 2026-07-09 23:04:28 | Last assistant entry ever written to the session JSONL | session JSONL |
| 2026-07-09 23:05:41 | /usage | history.jsonl |
| 2026-07-09 23:05:52 | /logout — last history.jsonl entry for this project | history.jsonl |
| 23:05 → next day ~11:30 | User re-logged in, ~12h of active conversation (many prompts, many tool calls, files written) | none — nothing persisted |
| 2026-07-10 11:51 | JSONL mtime still being updated, content still ends at 23:04 | file system |

Additional context that may matter:

• The session was long-running (multiple days) and had gone through context

compaction earlier.

• The machine had both v2.1.201 and v2.1.204 sessions on disk (auto-update had

happened at some point during the session's lifetime).

Relationship to existing issues

Symptom is identical to #53417 ("Resumed sessions silently stop writing to session
JSONL after claude.exe version upgrade", closed as not planned) — but the trigger
here is different and precisely timestamped: in-session /logout, matching to
within ~1 minute of the last persisted message. This suggests the JSONL writer (and
history writer) are torn down on logout and never re-initialized after re-auth.

Expected behavior

Either (a) persistence resumes after re-login, or (b) if the transcript writer is
in a dead state, the session should refuse input / warn loudly — anything but
silently discarding hours of transcript while the file mtime keeps updating.

Environment

• Claude Code v2.1.204, native Windows (cmd.exe), Windows 11 Pro (build 26200)
• Team plan, interactive CLI session (entrypoint: cli)

How we detected it

We compare each session JSONL's file mtime against the timestamp of its last
user/assistant entry; a large gap while the file is still being touched is the
fingerprint of this bug. Suggestion: Claude Code itself could self-check this
invariant and warn.