Repository navigation
JSONL cross-session contamination: all event types written to wrong session file when multiple sessions are active #26964
Description
What's Wrong?
When multiple sessions are active in the same project directory, JSONL entries from one session are written into another session's JSONL file. All event types are affected — not just custom-title, but also assistant, user, system, progress, and queue-operation.
The cross-writes are bidirectional: session A's file contains entries from session B, and session B's file contains entries from session A. Events from different sessions are interleaved at sub-minute (sometimes sub-second) intervals within a single JSONL file.
Quantified impact
Three affected sessions (bfcfcd91, a5d6b936, 9600a743) in the same project:
| File | Entries with sessionId | Cross-session entries | Contamination rate |
|---|---|---|---|
bfcfcd91 |
61 | 26 | 42.6% |
a5d6b936 |
1,184 | 276 | 23.3% |
9600a743 |
321 | 246 | 76.6% |
Other JSONL files (7) in the same project directory are completely clean.
What Should Happen?
Each session's JSONL file should only contain entries belonging to that session. Entries should never leak into a different session's file.
Steps to Reproduce
Exact reproduction steps are not confirmed. Suspected trigger:
- Have multiple Claude Code sessions active simultaneously in the same project directory
- Interact with them in overlapping time windows
- Inspect the JSONL files — entries from different sessions will be interleaved in each other's files
Note: /resume was not used in the affected sessions (confirmed by scanning all entries for isResume, resumeFrom, source: "resume" — none found). This distinguishes this issue from #26563, which is triggered by /resume.
Evidence
Timeline interleaving in a5d6b936.jsonl
L599: a5d6b936 ts=16:04:11 (own session)
L605: 9600a743 ts=16:26:37 ← 22min jump, foreign session injected
L617: a5d6b936 ts=16:33:37 ← back to own session
L627: bfcfcd91 ts=16:35:15 ← another foreign session
L646: a5d6b936 ts=16:36:21 ← back to own session
...
L1040: a5d6b936 ts=18:01:33
L1041: bfcfcd91 ts=18:01:36 ← 3 seconds later, different session!
L1043: a5d6b936 ts=18:01:49 ← 13 seconds later, back again
Cross-written event types in a5d6b936.jsonl
141× assistant (from bfcfcd91)
98× user (from bfcfcd91)
12× system (from bfcfcd91)
12× progress (from bfcfcd91)
4× user (from 9600a743)
3× assistant (from 9600a743)
3× custom-title(from bfcfcd91)
2× system (from 9600a743)
1× custom-title(from 9600a743)
Impact
- Session history is unreliable: JSONL files may contain conversations from other sessions mixed in
- Session names corrupted:
custom-titlecross-writes cause wrong names in the resume picker - Debugging is extremely difficult: a single JSONL file may contain interleaved entries from 3+ sessions
Claude Code Version
2.1.47 (Claude Code)
Platform
Anthropic API (subscription)
OS
macOS 14.6 (Darwin 23.6.0)
Related Issues
- Hook payload session_id misattributed after /resume #26563 — Hook payload session_id misattributed after
/resume(different trigger:/resumevs concurrent sessions; unidirectional vs bidirectional; may share underlying root cause) - Session names from /rename are lost after resuming and continuing work #26240 — Session names lost after resume
- [BUG] Renamed session works on first resume but the name disappears after the second exit #25090 — Auto-titler overwrites manual /rename
- 🐛 customTitle not restored when resuming session via --resume <session-id> #24809 — customTitle not restored on resume
Activity
github-actions commentedon Feb 19, 2026
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
MitsunChieh commentedon Feb 19, 2026
This is not a duplicate of #26563 or #24775.
Updated findings — the problem is much larger than custom-title
After deeper analysis of the raw JSONL files, the cross-session writing is not limited to
custom-titleevents. All event types are affected:bfcfcd91a5d6b9369600a743Cross-written event types include:
assistant,user,system,progress,queue-operation, andcustom-title. The events from multiple sessions are interleaved at sub-minute intervals in a single JSONL file.Why this is not #26563
/resumeused — confirmed by scanning all JSONL entries/resume/resumeWhy this is not #24775
#24775 is about
CLAUDE_ENV_FILEpath mismatch — a completely different subsystem (environment variables vs JSONL storage).Revised description
The original report focused on
custom-titlebecause that's where the issue was first noticed. The actual bug is broader: when multiple sessions are active in the same project, JSONL writes from one session can end up in another session's file. Thecustom-titlecross-write is just one visible symptom.This may share an underlying root cause with #26563 (session ID management defects), but the trigger path is different and fixing one may not fix the other.
[-]custom-title events for one session are written into a different session's JSONL file[/-][+]JSONL cross-session contamination: all event types written to wrong session file when multiple sessions are active[/+]gonewx commentedon Feb 20, 2026
This is a pretty serious data integrity issue. Cross-session contamination means you can not reliably review what happened in a specific session — the timeline is polluted with events from unrelated work.
For teams that need reliable session audit trails, this makes multi-session workflows risky. If you are working on a critical feature in one session and debugging in another, contaminated logs make it impossible to reconstruct what actually happened.
As a workaround, Mantra maintains independent session snapshots with proper isolation — each session gets its own timeline that you can browse, search, and restore. It watches the JSONL files but keeps its own clean index.
Hope this gets fixed upstream though — session isolation should be a guarantee at the storage layer.
github-actions commentedon Mar 21, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Mar 28, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.