[BUG] Session transcript never created: new interactive sessions run for hours writing no JSONL and no history.jsonl entries (silent, unrecoverable conversation loss)

Summary

Two interactive sessions (started ~10h apart, same folder) ran normally for hours but never created a session transcript at all. The session directory ~/.claude/projects/<project>/<session-id>/ was created and written to (tool-result externalisation landed there), but the sibling ~/.claude/projects/<project>/<session-id>.jsonl was never created, and zero entries were ever appended to ~/.claude/history.jsonl for that project.

The conversations worked perfectly in every other respect: prompts, tools, MCP calls, file writes. The only symptoms were at the edges:

• /branch → "no conversation to branch"
• On quit, no claude --resume hint printed
• The session does not appear in claude --resume at all
• The conversation is unrecoverable

This is not a deletion. It is the transcript writer never initialising.

Why we are confident it was never written (not deleted)

• The session dir exists with tool-results/ populated (files written at 14:57), but no .jsonl ever appeared next to it.
• ~/.claude/history.jsonl is a single shared append-only file. It has zero lines for this project across its entire lifetime, while ~69 prompts from other projects landed in the same window. A deletion would have to surgically remove interleaved lines from that shared file, which nothing does.
• Nothing in Trash. No orphaned .jsonl anywhere on disk. No deleted-but-open file handle. No cleanupPeriodDays set. 140 GB free. Directory writable, not a symlink, same device.
• Of 114 transcripts on disk, these were the only sessions with no transcript at all.

Reproduced once, live

A follow-up session started in the same folder the next day exhibited the identical failure while investigating the first one: no transcript, no history entries. So it is not a one-off corruption of a single session.

Not reproducible on demand

Same command, same cwd, same version, hours later: persists correctly (146 KB transcript written within seconds of the first prompt). Also verified fine in fresh scratch folders, and via a headless claude -p run in the affected folder. The environment is not the cause. It appears to be an intermittent failure of session-persistence initialisation.

Steps to reproduce (intermittent)

1. cd <some folder>
2. claude --dangerously-skip-permissions (started by hand in Terminal.app, interactive)
3. Work normally for a while
4. Observe: no <session-id>.jsonl in ~/.claude/projects/<project>/, no entries in ~/.claude/history.jsonl, /branch fails, session absent from claude --resume

Expected behavior

If the transcript writer fails to initialise, the session should say so loudly rather than run for hours and silently discard the conversation. A cheap self-check: after the first assistant turn, assert the transcript path exists and is non-empty; if not, warn in the TUI.

Relationship to existing issues

• #76267 — in-session /logout tears down persistence mid-session and never restores it. Same failure class (transcript + history writers dead while the session runs on), different trigger: here there was no /logout, and the transcript was never created in the first place rather than stopping partway.
• #53417 — resumed sessions silently stop writing to session JSONL after a version upgrade (closed as not planned).

The common thread across all three: the persistence layer can be in a dead state while the session appears completely healthy, and the user only discovers it when the conversation is already gone. Whatever the individual triggers, the invariant "a running session is being persisted" is never checked.

Workaround (for anyone hitting this)

A UserPromptSubmit hook that checks the transcript_path it is handed and warns if the file is missing or empty. Give the first prompt of a session a grace pass, since the transcript is written lazily, or every healthy session false-alarms. This turns hours of silent loss into a warning within one prompt.

Environment

• Claude Code 2.1.207
• macOS (Darwin 25.5.0), Apple Silicon
• Interactive CLI session started by hand in Terminal.app, --dangerously-skip-permissions
• Both affected sessions used MCP servers and tool-result externalisation, both of which worked normally