Sessions on claude-fable-5 stop writing local transcript JSONLs (~/.claude/projects/...) since ~2.1.209; Opus sessions on same binary write normally

Summary

Since roughly 2.1.209/2.1.210, interactive sessions running the model claude-fable-5 no longer write their local transcript to ~/.claude/projects/<encoded-cwd>/<session-id>.jsonl. Either no file is created at all, or a 0-byte stub appears at session start and never grows. Sessions running claude-opus-4-8 on the same 2.1.211 binary write a normal, growing transcript JSONL.

Resume still works for the affected sessions (consistent with server-side session storage, see #63904), so nothing breaks inside Claude Code itself. But every local integration that reads transcript JSONLs (statuslines, session monitors, transcript search and analytics tooling) silently goes blind for these sessions.

Environment

• Claude Code 2.1.211 (native install), macOS (Darwin 25.5.0)
• Also observed on sessions created under 2.1.210

Observation matrix (all on the same machine, same day)

| CC version | Model | Session type | Local transcript JSONL |
|---|---|---|---|
| 2.1.211 | claude-opus-4-8 | headless/spawned | written normally, grows per turn |
| 2.1.211 | claude-fable-5 | interactive | no file at all |
| 2.1.210-era | (interactive sessions) | interactive | 0-byte stub, never grows |
| 2.1.207 (long-running process) | claude-fable-5 | interactive | written normally, grows per turn |

Additional observations:

• Adjacent per-session storage still works for the affected sessions: ~/.claude/file-history/<sid>/ checkpoints, ~/.claude/tasks/session-*, ~/.claude/teams/session-*, and workflow subagent journals/metadata under the session directory are all written.
• The message content of an affected session exists nowhere on local disk. I content-searched for unique strings from a live fable session across ~/.claude (including all of projects/), the temp dirs, and ~/.claude.json, with zero hits. ~/.claude/history.jsonl also stopped receiving these sessions' prompts.
• Pre-existing JSONLs of sessions that get resumed onto ≥2.1.209 freeze: no new message content is appended, only trailing metadata records (last-prompt, mode, permission-mode, ai-title) get rewritten. This signature resembles #60984 (2.1.144/2.1.145, where only ai-title was written).
• An affected session was closed and resumed 45 minutes later with --resume and continued with full context, so persistence clearly exists server-side.

Configuration ruled out

• cleanupPeriodDays is set to 99999 (not 0, the known persistence-killing value from #23710)
• CLAUDE_CODE_SKIP_PROMPT_HISTORY is not set anywhere (env, shell rc files)
• No --no-session-persistence flag, no persistSession: false

A config cause also would not explain the split: the Opus and Fable sessions above ran under the same settings on the same binary.

Repro steps

1. On 2.1.211, start an interactive session with model claude-fable-5 and run a few turns.
2. find ~/.claude/projects -name "<session-id>.jsonl" returns nothing (or a 0-byte stub).
3. Start a session with claude-opus-4-8 and run a few turns. Its JSONL exists and grows.

Question

Is this intended behavior for fable sessions (server-side-only persistence), or a regression? If it is intended, it would be good to have it documented, since the per-project transcript JSONLs are a de-facto integration surface that a lot of local tooling builds on. If it is a regression, it looks like a sibling of #60984.

How I found it: a spawn helper of mine verifies a launched session by polling for its transcript JSONL. That check now false-negatives on every fable session, which sent the helper into a retry that double-injected a prompt. The transcript absence was the root cause.