Interactive session silently stopped persisting its transcript for 2+ weeks — inherited CLAUDE_CODE_CHILD_SESSION marker treated a primary user session as a child session

Summary

My main long-running interactive session (my "brain" session for a multi-week project) silently stopped writing its transcript to disk on Jul 9, while the session kept running normally for two more weeks (Jul 14–19 was heavy daily use: hundreds of tool calls, ~40–50% context used). Everything typed and generated after Jul 9 was permanently lost from the transcript. There was no warning at the time — the session looked completely normal.

Only after updating to a recent version (currently v2.1.215+) did the status line reveal the cause:

⚠ Transcript saving is off — inherited CLAUDE_CODE_CHILD_SESSION marker · restart with CLAUDE_CODE_FORCE_SESSION_PERSISTENCE=1 to keep future transcripts

The session had inherited the child-session environment marker — most likely because it was resumed from a terminal whose environment descended from another Claude Code process (I run a scheduled fleet of claude --print agents, and Windows Terminal tabs inherit the environment of the process that spawned them). From that point on, Claude Code classified my primary interactive session as a child session and dropped all transcript persistence — silently.

Environment

• Claude Code: bug active on ~v2.1.2xx (Jul 2026); warning line appeared after updating (v2.1.215 or later)
• OS: Windows 11 Home 10.0.26200
• Shell: Git Bash inside Windows Terminal
• Plan: Claude Max 5x; session ran Fable 5 / Opus 4.8
• Session ID: 212cc35b-6f1a-4ad3-a397-ed25fd18c535 (project dir C--Users-david-Documents-MY-PORTFOLIO-agent-os)

Root cause — confirmed empirically (2026-07-23)

• env inside the affected live session shows CLAUDE_CODE_CHILD_SESSION=1 — the session process itself carries the marker.
• The marker is exported to every subprocess of a Claude session (verified from a Bash tool call). So any terminal tab, wt.exe window, or script launched from inside any Claude session inherits it — and any claude later started in that environment is silently classified as a child session with transcript persistence disabled.
• Likely carrier in my case: a session-restore workflow that opens Windows Terminal tabs (via wt.exe) with claude --resume pre-filled, invoked from inside a running Claude session. Every restored tab inherited the marker; resuming my primary session from such a tab permanently flipped it to "child" behavior on each subsequent resume.

Timeline / evidence (all verifiable on my machine)

1. Session transcript 212cc35b-….jsonl — last record Jul 9, 12:41 UTC; file never grew again (verified repeatedly, including today Jul 23 while the session was actively in use).
2. ~/.claude/logs/session-212cc35b.log (per-session tool log) — proves hundreds of tool calls Jul 14–19, i.e. the session was alive and heavily used while zero transcript records were written.
3. Resuming the session repeatedly (including after claude update) reproduced it: each resume kept inheriting the marker; every conversation after Jul 9 vanished on next resume.
4. After the CLI update, the status line now shows the ⚠ Transcript saving is off — inherited CLAUDE_CODE_CHILD_SESSION marker warning in this session.
5. Partial self-rescue: the session had run /export on Jul 6, Jul 16, and Jul 20, so some chat was recovered; Jul 17–19 conversation is permanently gone.
6. Related papercut: on Jul 20, bare /export and /export tragedy.txt in this session both failed with Failed to export conversation: EEXIST: file already exists, mkdir 'C:\Users\david\Documents\MY_PORTFOLIO\agent-os' — exporting to a subpath (docs/name.txt) worked.

Why this is severe

• Silent, long-duration data loss on the exact session type users care most about (long-lived primary sessions). Weeks of conversation lost with zero indication.
• The marker propagates invisibly through terminal environment inheritance — any user who ever opens a terminal (or whose terminal app was launched) from within a Claude-spawned process can poison their real sessions.
• --resume of an interactive, TTY-attached session should arguably never be treated as a child session, regardless of environment.

Suggested fixes

1. Don't classify TTY-attached interactive sessions as children — clear/ignore CLAUDE_CODE_CHILD_SESSION when stdin is a TTY, or at minimum on --resume of an existing user session.
2. The new warning is good — but make it blocking/loud on interactive startup (a one-time confirm), not a status-line footnote; the failure mode is silent data loss.
3. Consider a periodic integrity check: if a session has produced N messages with zero transcript flushes, surface an error.
4. Fix the /export EEXIST failure when exporting to the CWD on Windows.

Ask

Primarily reporting so this gets fixed. If any server/local recovery of the Jul 14–19 transcript records is possible, I'd love to hear it, but I understand they were likely never written.