Session conversation .jsonl files not written when using parallel subagents — history permanently lost

Describe the bug

Multiple sessions have lost their conversation history. Sessions appear in the sidebar with dashed/empty icons and no content. The session directories exist and contain populated \subagents/\ folders — proving the sessions ran — but there is no top-level \<session-id>.jsonl\ conversation file.

This is distinct from #51412 where the \.jsonl\ files exist but the index is broken. In this case, the \.jsonl\ files were never written (or were deleted), while the subagent files are intact.

To reproduce

Run sessions that spawn large numbers of parallel subagents (e.g. 10–70 concurrent agent calls per session). The main conversation transcript appears to fail to write while subagent transcripts succeed.

Expected behaviour

A \<session-id>.jsonl\ file should exist alongside the \<session-id>/subagents/\ directory after every session.

Actual behaviour

\\\
~/.claude/projects/-Users-peteradmin-bid-writer-clean/
├── d934fc2a-9720-4b1a-a618-c00684417698/ ← directory exists
│ └── subagents/ ← 60+ subagent .jsonl files
│ ├── agent-ad19627.jsonl
│ └── ...
│ ← NO d934fc2a-....jsonl here
├── 6e4dc774-4c8b-4cd4-9edc-afa0381b89b8/ ← healthy recent session
└── 6e4dc774-4c8b-4cd4-9edc-afa0381b89b8.jsonl ← .jsonl exists ✅
\\\

All sessions from March–April 2026 are affected. Only the most recent session is healthy.

Environment

• Claude Code version: 2.1.109
• OS: macOS 25.3.0 (Darwin)
• Entrypoint: claude-desktop
• Affected project: \/Users/peteradmin/bid-writer-clean\

Impact

Several months of conversation history is unrecoverable. The subagent files prove the sessions ran, but the main conversation transcript (user messages + Claude responses) is permanently lost.

Suspected cause

Heavy parallel subagent usage. Each affected session spawned 10–70 concurrent subagents. My hypothesis is a race condition or write failure in session file flushing when many subagents are active simultaneously.

Related issues

• #51412 — similar data loss symptom but different root cause (index corruption, not missing .jsonl)