[BUG] New Claude sessions appear and claude CLI loses track of sessions when context limit reached
[EDIT] to add related bug in body.
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
I have several long-running claude CLI session.
In the last week, I noticed claude losing track of sessions. For example, given the following sessions structure:
- coder
- tester
- code-reviewer
I suddenly can no longer find the "code-reviewer" session (see https://github.com/anthropics/claude-code/issues/97242), and I find multiple "coder" sessions.
Looking at the session files in .claude/projects/<project-path>/*.jsonl, I find 3 sessions whose user prompt history matches the "coder" session, let's call these 1.jsonl, 2.jsonl, and 3.jsonl. Two of the jsonl's (2.jsonl and 3.jsonl) start with:
This session is being continued from a previous conversation that ran out of context.
Furthermore:
- The final user prompts of 2.jsonl match the initial user prompts of 3.jsonl.
- But the first ~60% of 2.jsonl overlaps with the final ~10% of 1.jsonl
The estimated overlap is done by piping the jsonl files through jq to pretty print, matching the actual user prompt (e.g. "Fix issue number xyz" or "Code review complete, you can continue"), and noting the % position in less. I did not diff the suspect overlapping portions of the file to see if they matched.
Furthermore, if I try to resume the "coder" session that matches 3.jsonl, it tells me it is it is a background session and to claude stop 3 or claude attach 3, but:
- when I try to
claude stop 3it tells me it's stopped, but if Iclaude -r 3it gives me the same background session message claude attach 3works- I also find remote-control is attached to this session
In my config, Autocompact is set to true. The threshold is probably the default.
Note that I have had long running sessions for months, and this issue only recently surfaced (in the last week or two).
What Should Happen?
- Prompt to compact instead of starting new sessions
- Don't create new sessions without telling the user
- Don't autocreate new sessions with the same user-assigned name
- Don't lose track of sessions
Error Messages/Logs
None.Steps to Reproduce
Not sure how to repro.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown, probably from ~10-14d previous
Claude Code Version
2.1.282
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
iTerm2
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Seeing this same session-duplication pattern when autocompact fires mid-task. The root problem you're describing is that the state the coordinator relies on (which sessions exist, what they were doing) lives entirely inside the processes themselves, so when the CLI duplicates or loses a session it has no external ground truth to reconcile against.
One approach that has helped in our setup: keep a thin out-of-process record for each session (owner token, task description, last-heartbeat) in a file or lightweight store, and have the coordinator check that record rather than relying on the CLI's own session list. When a session duplicates or goes zombie you can detect it via the heartbeat gap and either reattach or restart cleanly instead of trying to reconstruct what happened from overlapping JSONL files.
Still does not fix the CLI-level bug you're reporting (the split-and-lose behavior should not happen), but an external ledger makes recovery deterministic rather than dependent on inspecting partially-overlapping session files.
This is the same durability gap that motivated https://claudeverse.ai -- the coordinator keeps its cycle record outside any one agent so a crash or context-limit event does not corrupt shared state. Happy to share more on the pattern if useful.
Not a fix for the CLI bug, but a way to make it less costly while it is open: keep each named session's state in a file in the repo, not only in the session. Have it write a short checkpoint (what is done, which commits) before long runs, and start any new or duplicated session by reading that file. Then a lost session costs minutes, not the work. Disclosure: I maintain Succession, a free MIT plugin that does this per named session: https://github.com/thecontinuitylayer/succession
The .jsonl filename is the session ID, so you can resume a specific one directly: run
claude --resume <uuid>from that project's directory. To search those local transcripts across projects, I built Sesame (I'm the author), a free macOS app that reads ~/.claude/projects locally: https://github.com/qiwei66/sesame