[BUG] A single metadata-only stub transcript makes /resume list empty for the ENTIRE project — 33 sessions hidden by one 416-byte file (2.1.210, macOS) #77898

Summary

A single malformed "stub" transcript in ~/.claude/projects/<key>/ causes /resume to
show an empty list for that entire project. Not just the bad session — every
session in the folder disappears from the picker.

In my case one 416-byte file hid 33 healthy sessions, including multi-MB ones
from the same day. Deleting/moving that one file restored the full list immediately.

The transcripts are never damaged. claude --resume <id> restores them perfectly the
whole time — so this is purely a listing/enumeration bug, not data loss. But from the
user's side it is indistinguishable from "my history is gone", which is why I suspect it's
under-reported.

Environment

• Claude Code: 2.1.210 (native install, ~/.local/bin/claude)
• OS: macOS (Darwin 25.5.0)
• Shell: zsh
• Not VS Code — plain CLI.

The offending file

A transcript containing only metadata records — no cwd, no timestamp, no user or
assistant messages:

{"type":"ai-title","aiTitle":"connectivity-check","sessionId":"<uuid>"}
{"type":"agent-name","agentName":"connectivity-check","sessionId":"<uuid>"}
{"type":"ai-title","aiTitle":"connectivity-check","sessionId":"<uuid>"}
{"type":"agent-name","agentName":"connectivity-check","sessionId":"<uuid>"}

Mine was written by a daemon-backed background job (template: bg, backend: daemon)
that was spawned but never prompted — its ~/.claude/jobs/<id>/state.json still reads:

state: working
tempo: blocked
needs: send a prompt to start

So the session got named (ai-title/agent-name written) but never had a first turn,
leaving the transcript as pure metadata.

I found the same stub shape in 2 other projects on this machine, with ordinary work titles
("Review fixed code changes", "Change packaged executable naming") — so this is not
specific to background jobs. Any session that is titled and then abandoned before its
first turn appears to produce one.

Symptom

That third row is the key discriminator: resume-by-ID works while the listing is empty.
Storage is fine; the enumerator is what's failing.

Steps to reproduce

1. Pick a project with several existing sessions; confirm /resume lists them.
2. Write a stub transcript into that project's folder:

UUID=$(uuidgen)
cat > ~/.claude/projects/<encoded-cwd>/$UUID.jsonl <<EOF
{"type":"ai-title","aiTitle":"stub","sessionId":"$UUID"}
{"type":"agent-name","agentName":"stub","sessionId":"$UUID"}
EOF

3. Run /resume in that project → list is empty; all previously-listed sessions gone.
4. Remove the stub → list returns in full.

Likely cause

The picker appears to read each .jsonl for a sort key (timestamp/mtime) and a filter key
(cwd), and a record possessing neither seems to throw — aborting the whole directory scan
rather than skipping the entry. A malformed or unrecognised transcript should be skipped,
not fatal to its siblings.

Impact

Severity is amplified by how invisible the cause is:

• Presents as total, silent loss of a project's history. Nothing points at a 416-byte file.
• The data is fine, so users may re-do work or abandon context they still have.
• Self-inflicting: any abandoned/never-prompted session poisons the project it was
  launched from, and the stub sources ([BUG] Programmatically-spawned sessions intermittently write a stub transcript (ai-title only) + no sessions/<PID>.json -> not resumable (2.1.173, Windows) #68435, Regression in 2.1.144/2.1.145: conversation JSONL files only save ai-title, no message content written to disk #60984) are themselves live bugs.

Detection script

Finds stub transcripts across all projects:

python3 -c "
import json,glob,os
for f in glob.glob(os.path.expanduser('~/.claude/projects/*/*.jsonl')):
    has_cwd=has_user=False
    for line in open(f):
        line=line.strip()
        if not line: continue
        try: d=json.loads(line)
        except: continue
        if d.get('cwd'): has_cwd=True
        if d.get('type')=='user': has_user=True
    if not has_cwd and not has_user: print('STUB:', f)
"

Workaround

Move the stub out of the project folder (mv <stub>.jsonl /tmp/). They contain no
conversation, so nothing is lost. The picker recovers instantly — no restart needed.

Suggested fix

Make the enumerator defensive: wrap per-file parsing in a try/catch and skip files with no
usable timestamp/cwd rather than failing the directory. Optionally, don't persist an
ai-title/agent-name record until a session has its first real turn — that would stop
stubs being created at all.

Related

• [BUG] Programmatically-spawned sessions intermittently write a stub transcript (ai-title only) + no sessions/<PID>.json -> not resumable (2.1.173, Windows) #68435 — programmatically-spawned sessions writing ai-title-only stubs (a source of
  the malformed input; that report's symptom is the stub session itself being unresumable,
  whereas here the stub takes down every other session in the project).
• Regression in 2.1.144/2.1.145: conversation JSONL files only save ai-title, no message content written to disk #60984 — 2.1.144/145 regression writing ai-title-only JSONLs (another stub source).
• bug: Sessions missing from claude --resume list #57203 — "sessions missing from --resume list", macOS, notes "sessions from certain
  projects/contexts are not included". Undiagnosed, but that per-project pattern is
  consistent with this root cause; may be the same bug.