[BUG] **Session transcript writes to wrong JSONL file — cross-session data corruption** #29342

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Claude Code is writing conversation entries (user, assistant, progress) to a JSONL file belonging to a different session. This corrupts the target session, making it unresumable or showing mixed content from unrelated conversations.

What Should Happen?

No session/conversation leaking

Error Messages/Logs

Steps to Reproduce

This is a persistent, self-reproducing bug. Exact trigger conditions are unclear, but the following setup reliably produces it:

1. Session A (8c7f654b) was originally created from directory /home/user/Dev/project/ (path A)
2. The project was later moved/restructured to /home/user/Dev/project-v2/ (path B)
3. Session A's JSONL file exists in both project scopes:
   • ~/.claude/projects/-home-user-Dev-project/8c7f654b.jsonl (old, 503 lines, untouched)
   • ~/.claude/projects/-home-user-Dev-project-v2/8c7f654b.jsonl (new-path copy)
4. Session B (719d38ef) is started from path B — a completely different session
5. Session B's entries start appearing in Session A's JSONL file at path B

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.62 (also observed on 2.1.59)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Observed Behavior

• Session B (719d38ef) writes its entries to both:
  • Its own file: ~/.claude/projects/.../719d38ef.jsonl (correct)
  • Session A's file: ~/.claude/projects/.../8c7f654b.jsonl (WRONG)
• When Session B is /compact-ed into Session C (c1bf1377), the bug persists — Session C also writes to Session A's file (with Session B's session ID in the entries)
• Multiple unrelated sessions (b74066a3 — "Rice Claude") also leak entries into Session A's file
• The leaked entries are full conversation data (user messages, assistant responses, progress events) — not just metadata
• Cleaning the file only provides temporary relief — entries re-appear within seconds from the active session

Evidence

# Session IDs found in 8c7f654b.jsonl (should ONLY contain 8c7f654b entries):
1768  8c7f654b-460b-4b7a-b7f3-ae29cfb220e3  (correct)
 130  null                                      (file-history-snapshot, correct)
  89  719d38ef-3348-4d70-9d5b-3e00a274a4d0    (WRONG — different session)
   5  b74066a3-1dea-414c-9299-4658945b4e42    (WRONG — different session)

# Type breakdown of leaked entries from 719d38ef:
  40 assistant
  25 progress
  24 user

After cleaning the file, 6 new foreign entries appeared within 3 seconds:

{"sessionId":"719d38ef-...","type":"progress","ts":"2026-02-27T14:28:39.044Z"}
{"sessionId":"719d38ef-...","type":"user","ts":"2026-02-27T14:28:39.082Z"}
{"sessionId":"719d38ef-...","type":"assistant","ts":"2026-02-27T14:28:42.728Z"}

Key Details

• The corrupting session writes entries with its own session ID into the victim file — so entries can be filtered by sessionId, but should never be there in the first place
• The bug survives /compact — when session 719d38ef was compacted into a new session c1bf1377, the new session continued writing to the wrong file (still using the old 719d38ef session ID)
• The victim session (8c7f654b) was originally created from a different project path — the JSONL file exists in two project scopes. This may be a factor in the write-target confusion
• Cleaning the file from within the corrupting session is futile — it re-corrupts immediately

Impact

• Session corruption: The victim session becomes unresumable or shows garbled content
• Data leak between sessions: Conversation content from one session is written to another session's file — potential privacy concern if sessions belong to different contexts
• Persistent: The bug survives session compaction and continues across session continuations

Workaround

The only workaround is:

1. Exit ALL sessions that might be leaking
2. From a brand new session (not resumed/continued), run:

jq -c 'select(.sessionId == "<victim-session-id>" or .sessionId == null)' victim-file.jsonl > /tmp/clean.jsonl
mv /tmp/clean.jsonl victim-file.jsonl

3. Hope the new session doesn't also target the wrong file

Possible Root Cause

The write queue or file descriptor targeting appears to be associated with a session JSONL filename/path rather than being strictly tied to the active session's ID. When a session file exists in a project scope (perhaps leftover from a path change), new sessions may inadvertently open append handles to it.