[BUG] Silent total transcript loss in stock macOS Terminal.app — 12h session wrote no .jsonl and no history entries, workflow sidecars persisted fine (same signature as #79188, no multiplexer)
Summary
A ~12-hour interactive Claude Code session in stock macOS Terminal.app (no tmux/screen/multiplexer of any kind) persisted nothing: the transcript .jsonl was never created, and none of the session's prompts were written to ~/.claude/history.jsonl. The session is silently and permanently unrecoverable — --resume cannot find it, and no error or warning was shown at any point. An in-session /rename was also lost with everything else.
The failure signature is identical to #79188 ("Transcript persistence is silently skipped depending on the hosting terminal"), which isolates the hosting terminal via a controlled A/B — but that report reproduces it in a third-party multiplexer pane. This report shows the same signature in the default macOS terminal with no multiplexer involved, so the trigger space appears wider than exotic terminals. Possibly also related: #63545 (tmux, "transcript not saved").
Failure signature
~/.claude/projects/<slug>/<sid>/workflows/… ✅ created (workflow run json, script, journal.jsonl — all intact)
~/.claude/projects/<slug>/<sid>/subagents/… ✅ created (agent meta files)
~/.claude/projects/<slug>/<sid>.jsonl ❌ never created
~/.claude/history.jsonl ❌ zero entries for any of the session's prompts
Exactly as in #79188: everything written eagerly during the session survives; the transcript and history — the buffered/deferred parts — were never written at all.
Environment
- macOS, Darwin 25.5.0, zsh, Terminal.app (only terminal emulator installed/running; verified no tmux, screen, zellij, herdr, or any other multiplexer)
- Claude Code via the
~/.local/bin/claudelauncher - Version ambiguity worth noting: the session was launched at 01:45:36 local; the auto-updater installed 2.1.215 at 01:45:38 (two seconds later). Previously installed version was 2.1.211. So the session ran on 2.1.211 or 2.1.215 depending on launcher behavior at that instant.
- A long-lived background daemon from an older install was running at the time (
claude restartwas only executed ~13 hours later) - claude-code-router is installed and its daemon was running on the machine, but the session was launched with plain
claude(noccr), so it should not be in the path - Affected session id:
f36b7231-640d-49c8-b5d6-f0a5836bade8(in case server-side telemetry can be correlated)
Timeline (local time, from shell history + filesystem timestamps)
| time | event |
|---|---|
| 01:45:36 | claude launched in a project directory (plain invocation, no flags) |
| 01:45:38 | auto-updater installs 2.1.215 (birth time of ~/.local/share/claude/versions/2.1.215) |
| 01:45 → ~14:02 | interactive session (likely idle overnight, active in the morning); /rename performed at some point |
| 13:52:34 | session runs a Workflow — sidecar dir <slug>/<sid>/ born (proves the session id and project) |
| 14:02:11 | workflow completes (final journal.jsonl write) |
| 14:32–14:39 | repeated claude --resume attempts find no such session; claude restart; claude update |
| aftermath | session absent from every store: projects dir, history.jsonl, desktop-app session index |
Why this is "never written", not "deleted later" (post-hoc forensics)
- Parent slug directory mtime never moved. The
~/.claude/projects/<slug>/directory's mtime stayed at 13:52 (creation of the sidecar dir) until an unrelated new session at 14:54. Any create-then-delete of the transcript file would have bumped it. There was never a<sid>.jsonlin that directory. - Full-tree sweep:
find ~/.claude -newermt 01:00 ! -newermt 14:35returns only the workflow sidecar files. Nothing else under~/.claudewas written during the entire session. - No crash reports for the period, no APFS snapshots or Time Machine involved,
~/.claude/file-history/and~/.claude/debug/empty for the session.
Impact
~12 hours of design/analysis conversation silently lost. The only survivors were the workflow's structured outputs (eager writers). The user experience is brutal: the session looked completely healthy the whole time — workflows ran, rename appeared to succeed — and the loss is only discoverable after exit, when it's unrecoverable.
What I can't provide
No controlled repro — this was discovered after the fact. Sessions started on this machine after the 2.1.215 update (same Terminal.app, same user, same project) persist their transcripts normally within seconds of launch, so it is either fixed in 2.1.215, intermittent, or dependent on launch-time state (e.g., the concurrent auto-update two seconds after launch, or the stale pre-update daemon).
Report compiled via filesystem forensics with Claude Code on the affected machine.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗