bug: Sessions missing from claude --resume list

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/25032
2. https://github.com/anthropics/claude-code/issues/49128
3. https://github.com/anthropics/claude-code/issues/46522

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

<img width="657" height="289" alt="Image" src="https://github.com/user-attachments/assets/9d1f9d53-bdff-4ca3-a318-647c76d9e897" />
<img width="861" height="757" alt="Image" src="https://github.com/user-attachments/assets/c0b402dc-f1d9-4b76-ba85-c00af056731a" />
<img width="896" height="1237" alt="Image" src="https://github.com/user-attachments/assets/93e488f2-6d7b-45b4-9b33-fb7810e9147e" />
<img width="2524" height="952" alt="Image" src="https://github.com/user-attachments/assets/0d9087cc-49b3-4def-a2dc-4811e8c8e9d5" />

Ran into this less than an hour after creating a session. Was given a resume ID (3184712f-12a7-4759-862a-d3b862a9d2d2) via the /resume link, but running /resume 3184712f-12a7-4759-862a-d3b862a9d2d2 returned "Session was not found." The session also did not appear in the /resume picker list. This was on macOS, same machine, same working directory, within ~1 hour of the original session.

The picker just isn't reading them correctly. The underlying JSONL is intact; you're not losing work.

Workaround that's gotten me unstuck:

Pass the session ID directly — you don't need to go through the picker:

# The resume command Claude prints at the end of a session includes the session ID
# You can also find it in the project directory:
ls ~/.claude/projects/<your-project-dir>/

# Then resume directly by ID
claude --resume <session-uuid>

If you don't remember the ID but remember what you were working on, I built a small open-source CLI called ccfind (claude-grep) specifically for this — it does full-text search across all your ~/.claude/projects/ JSONL files, bypassing the broken index entirely. You search by anything you remember from the conversation (function name, error message, question you asked), and it gives you a one-keypress resume. Sharing it here since it was born from this exact frustration — full disclosure, I'm the maker.

The root cause here seems to be the sessions index not updating reliably (related to #26123). Would be good to get a fix upstream, but at least the data isn't gone.

So, I've had this issue as well and I've found a potential cause (or Claude found it ;))

In my case, I started the session via --remote-control. That caused the session to get "entrypoint":"sdk-cli".

It seems that the picker is ignoring all sessions that have that entrypoint entry. Modifying that to "entrypoint": "cli" caused the sessions to get actually listed.

Additional reproduction case: in-session /resume causes permanent session data loss (Windows)

Environment

• Claude Code v2.1.186
• Windows 11 (Git Bash)
• Using plugins (oh-my-claudecode, agentmemory)

Steps to Reproduce

1. Start a Claude Code session (Session A) and do some work
2. Within the active session, use /resume to switch to a different session (Session B)
3. Session A's .jsonl file is never written to disk — it is permanently lost

Evidence

Inspecting ~/.claude/projects/<project>/:

• 14 .jsonl files exist, but none correspond to sessions from today (2026-06-23) or yesterday (2026-06-22)
• Multiple sessions were created on those days, but their .jsonl files were never persisted
• The issue is not an index/picker problem — the raw .jsonl files themselves do not exist on disk
• This happened repeatedly: working in Session A → /resume → Session A vanishes entirely

Key difference from the original report

This is not just "session missing from the picker list" — the session data is permanently destroyed. The .jsonl file is never flushed/written when switching sessions via in-session /resume. This means:

• claude --resume <session-id> also cannot recover it (there is nothing to resume from)
• The conversation history, tool outputs, and all context are irreversibly lost

Workaround

Avoid using /resume within an active session. Instead:

1. Exit Claude Code (/exit or Ctrl+C)
2. Resume from the terminal: claude --resume or claude -c

This ensures the current session's .jsonl is properly flushed before switching.

Correction & updated root cause (follow-up to my comment above)

After further investigation, my earlier comment was incorrect in attributing the data loss to in-session /resume. The actual root cause is different and more fundamental:

Actual root cause: sessions started inside tmux never create .jsonl files

Any Claude Code session started inside a tmux (psmux) session fails to persist its transcript — the .jsonl file in ~/.claude/projects/<project>/ is never created. This is independent of /resume.

Evidence

| Launch context | --teammate-mode | .jsonl created |
|---|---|---|
| Normal terminal (no tmux) | (none) | ✅ Yes |
| Inside tmux | tmux (auto-injected) | ❌ No |
| Inside tmux | in-process (explicit CLI flag) | ❌ No |
| Inside tmux, with $env:TMUX cleared | tmux (still auto-injected) | ❌ No |

Key findings from --debug-file output:

1. [TeammateModeSnapshot] Captured from CLI override: tmux — Claude Code auto-detects tmux and injects --teammate-mode tmux into its own command line, even when the TMUX env var is unset
2. Process inspection confirms: Get-CimInstance Win32_Process shows claude.exe --teammate-mode tmux for tmux sessions vs bare claude.exe for working sessions
3. [concurrentSessions] updatePidFile failed: ENOENT — repeated PID file write failures in ~/.claude/sessions/
4. No transcript-related log entries at all — the session persistence code path appears to be completely skipped
5. ~/.claude/session-env/<uuid>/ directories ARE created (session infrastructure works), but ~/.claude/projects/<project>/<uuid>.jsonl files are not

Environment

• Windows 11, Claude Code v2.1.186
• tmux via psmux (Windows tmux wrapper), launched from VS Code integrated terminal
• teammateMode: "auto" in settings.json (changing to "in-process" had no effect since the CLI auto-detection overrides it)

Impact

Since I primarily use Claude Code inside tmux, no session transcripts have been saved since 2026-06-16 — only pre-existing sessions that were resumed via --continue continued to be written to. All new sessions silently lost their data.

This is likely related to the teammate/team feature's tmux detection conflicting with users who run their primary Claude session inside tmux.

Adding a data point that reproduces on a current version (2.1.210), which might narrow this down.

Repro: I have several sessions whose .jsonl transcripts were initiated via the internal enqueue/dequeue queue mechanism (the file starts with {"type":"queue-operation","operation":"enqueue",...} / "dequeue" records before the first real user turn), rather than a normally typed-and-run command. For these sessions:

• /resume <session-id> — tried both an 8-char prefix and the full UUID — reports "Session was not found."
• The .jsonl transcript is fully intact and readable at ~/.claude/projects/<project>/<session-id>.jsonl.
• None of these session IDs appear in ~/.claude/history.jsonl (the {sessionId, project, display, timestamp} per-command index) by exact match — this may or may not be the actual file /resume's ID-lookup path consults; I don't have source access to confirm which index is authoritative here vs. sessions-index.json.

Proof it's a lookup bug, not data loss:

claude --resume <full-session-id> -p "Reply with only the words: RESUME OK"
# -> RESUME OK

This succeeds via the same --resume mechanism, on the identical session ID that /resume reports as not found — so the transcript and its data are completely fine; the bug is purely in discovery/lookup.

Hypothesis: sessions whose first turn arrives through the internal queue path (rather than a direct interactive prompt) may never get written into whatever index /resume's ID-based lookup checks, even when the .jsonl itself is written normally afterward.

Workaround for anyone hitting this: don't trust /resume's "not found" as proof of data loss — verify first with claude --resume <full-id> -p "test" from a shell.