[BUG] Silent session-transcript data loss keeps getting stale-closed (#53417, #70219): writer dies with zero errors — please fail loudly and add a write self-check

Summary

There is a class of bugs where the per-session transcript writer (~/.claude/projects/<project>/<uuid>.jsonl) dies or never starts silently: the session keeps working, tools run, responses stream, ~/.claude/history.jsonl updates, file mtime moves — but conversation turns are never appended. The user discovers the loss days later, when --resume comes up empty or truncated. This is unrecoverable data loss of user data, and both prior reports of it were closed by the stale-bot without a fix:

• #53417 — "Resumed sessions silently stop writing to session JSONL after claude.exe version upgrade". Closed 2026-06-02 as inactive, locked 2026-08-04. Never fixed.
• #70219 — "tmux/psmux auto-detection disables session transcript persistence — .jsonl never written". Closed as not planned.

We are a heavy multi-session Windows setup (~60 projects, many parallel sessions daily) and we have been pinned to 2.1.195 since July specifically because of this class. We would like to upgrade (Fable 5.1 requires 2.1.257) and cannot do it safely.

Incident that made us pin (2026-07-18, v2.1.205)

Three long-running interactive sessions (launched from a custom ConPTY-based terminal host, Windows 11) silently stopped appending turns after the CLI was upgraded and sessions were resumed. Every observable signal looked healthy:

• process alive, prompts accepted, responses generated;
• ~/.claude/history.jsonl kept updating;
• the per-session .jsonl mtime kept moving (metadata entries were still written);
• zero errors or warnings anywhere.

A full day of work across three sessions was lost, unrecoverably. The only reliable detection we found is content-based: grep the tail of the session .jsonl for recent user/assistant turns — mtime lies, because service entries keep touching the file.

New evidence for the #70219 leg (verified 2026-09-01)

Our terminal host used to set TERM_PROGRAM=tmux in the session environment (as a neutral fallback value, unrelated to actual tmux). Under 2.1.186+ auto-detection this classifies every session as a tmux teammate → transcript persistence is skipped entirely. Per #70219's reporter, the classification cannot be overridden: unsetting TMUX, setting --teammate-mode in-process, and settings.json were all ignored ([TeammateModeSnapshot] Captured from CLI override: tmux still appeared). We only avoided mass data loss because we audited our environment before upgrading and removed the variable ourselves.

Two implications:

1. Any terminal wrapper, IDE plugin, or CI environment that happens to carry tmux-ish environment markers loses transcripts wholesale, silently.
2. There is no supported way to say "this is a primary interactive session, ALWAYS persist the transcript".

Why stale-closing is the wrong tool here

Data-loss bugs are exactly the kind that go quiet for months: affected users either lose data silently (and cannot report what they cannot see), or pin an old version and stop generating new reports — which is what we did. Inactivity on such an issue signals successful avoidance, not resolution. Both closures happened with no reproduction attempt recorded.

What we ask for (in order of value)

1. Fail loudly. If the transcript writer is disabled (teammate classification) or a write fails, show a persistent in-session banner / stderr line: "Session transcript is NOT being persisted (<reason>)". One line turns an unrecoverable loss into a non-event.
2. Write-then-verify self-check. After appending a turn, verify it landed (size delta / read-back). On failure: loud error, not silence. The failure mode in #53417 is precisely a writer that thinks it writes.
3. An explicit, honored override to force transcript persistence regardless of teammate/tmux classification (flag or env var). #70219 shows the current overrides are ignored.
4. Triage this class as data loss, exempt it from stale-closing, and reopen or supersede #53417 / #70219.

Environment

• Windows 11 Pro 10.0.26200
• Claude Code pinned at 2.1.195 (npm), DISABLE_AUTOUPDATER=1
• Sessions run under ConPTY (custom host) and plain Windows Terminal; the bug class hit ConPTY-hosted resumed sessions
• Happy to run any diagnostics against 2.1.257 in a sandboxed install and report back — we have a reproduction protocol prepared (fresh session / plain terminal / ConPTY host / resume-of-old-session, verified by transcript content, not mtime).