[BUG] /resume is broken — session history inaccessible since v2.1.31 (3 root causes identified)

Related: #26125 (Ctrl+O/Ctrl+E broken — no way to view pre-compaction history)

These two issues compound: a user who can't find their session (#26123) AND can't view pre-compaction history within it (#26125) has no path to recover past work.

They may also share a root cause — both involve broken summary/metadata generation that correlates with the ~Feb 4 token-reduction changes. Bug 1 here (session summaries stopped being written, all new entries have "summary": "") and the poor-quality compaction summaries in #26125 may trace back to the same upstream change.

Great investigation on the 3 root causes. We've been dealing with resume issues too — built cozempic which has its own session detection that doesn't rely on sessions-index.json. It finds sessions by scanning the project directory directly and matching by CWD slug, process tree, or most-recent modification time. Also has a cozempic list command that shows all sessions regardless of the index state.

pip install cozempic
cozempic list              # shows all sessions with sizes
cozempic current           # finds current session for this project

Won't fix the /resume picker itself, but can help you find and identify sessions while the index is broken. Let us know if it helps.

Can confirm, sessions are completely broken, /rename, /fork.. nothing works properly, sessions disappear, strange nesting...

2.1.44 (Claude Code)
MacOS 15.5

Can confirm, sessions are completely broken, /rename, /fork.. nothing works properly, sessions disappear, strange nesting... 2.1.44 (Claude Code) MacOS 15.5

Please spread the word! we need 50 thumbs up on this issue in order to have a hope of getting it fixed. Issues below that threshold never get prioritized by anthropic team. Post on reddit, post on discord, tell your friends, etc! This issue is driving me crazy and this breakage -- which has been the case for weeks now -- it really doesnt have to be this way!

Confirming on v2.1.41, macOS (Apple Silicon). In-session /resume shows only 5 sessions; claude --resume from CLI shows 255. 314 valid .jsonl files on disk (211 on main branch), sessions-index.json stale since Feb 3.

Also experiencing a likely related regression: resuming a session in a second terminal now writes into the same session stream instead of creating an independent conversation. Both terminals end up sharing the same history (becomes visible if you fork again, or resume fresh). This used to work as two separate conversations.

I could even describe more of what feels now very "buggy" around session history and resuming — and a true hit on my workflows unfortunately — but I guess it's all related, so just waiting it out.

Adding a specific reproduction path: plan mode implementation sessions.

When you approve a plan in plan mode and select "Yes, clear context and auto-accept edits" (the default), Claude creates a new session to implement the plan. This session:

• Has a complete .jsonl file (367 lines in my case)
• Has userType: "external" and a valid slug
• Is not registered in sessions-index.json
• Does not appear in the --resume picker

This is particularly painful because plan mode implementation sessions often contain extensive file modifications. If interrupted, users cannot easily find or resume them.

Stats from my project directory: 156 .jsonl files, only 63 indexed (40% — consistent with your findings).

Closed my duplicate #26297 in favor of this issue.

Facing the same issue. When I create worktrees, the sessions made within a tree branch is not visible on /resume

Manual workaround: i created a bash script (temporarily) to find conversations and resume via /resume <hash-id>. I trigger this within the worktree folder that I am working on to resume.

  # Usage: ccfind <keyword> [project-filter]
  ccfind() {
    if [ -z "$1" ]; then
      echo "Usage: ccfind <keyword> [project-filter]"
      return 1
    fi
    for f in $(find "$HOME/.claude/projects" -maxdepth 2 -name "*.jsonl" ${2:+-path "*$2*"} -type f); do
      if grep -ql "$1" "$f" 2>/dev/null; then
        local id=$(basename "$f" .jsonl)
        local project=$(basename "$(dirname "$f")")
        local mod=$(stat -f "%Sm" -t "%Y-%m-%d %H:%M" "$f")
        local size=$(du -h "$f" | cut -f1)
        local snippet=$(grep -m1 "$1" "$f" | sed 's/.*"text":"//;s/".*//' | cut -c1-80)
        echo "$mod  $size  $id"
        echo "  project: $project"
        echo "  match:   $snippet"
        echo "  resume:  claude --resume $id"
        echo ""
      fi
    done
  }

Please spread the word! we need 50 thumbs up on this issue in order to have a hope of getting it fixed. Issues below that threshold never get prioritized by anthropic team. Post on reddit, post on discord, tell your friends, etc! This issue is driving me crazy and this breakage -- which has been the case for weeks now -- it really doesnt have to be this way!

Number of replies does not count towards human intervention?

> Please spread the word! we need 50 thumbs up on this issue in order to have a hope of getting it fixed. Issues below that threshold never get prioritized by anthropic team. Post on reddit, post on discord, tell your friends, etc! This issue is driving me crazy and this breakage -- which has been the case for weeks now -- it really doesnt have to be this way! Number of replies does not count towards human intervention?

Per claude:
does number of replies not count toward human intervention??

⏺ Yes they do! The oncall triage threshold is 50+ combined comments AND reactions, not just thumbs-up.

Thank you for pointing that out.

> > Please spread the word! we need 50 thumbs up on this issue in order to have a hope of getting it fixed. Issues below that threshold never get prioritized by anthropic team. Post on reddit, post on discord, tell your friends, etc! This issue is driving me crazy and this breakage -- which has been the case for weeks now -- it really doesnt have to be this way! > > > Number of replies does not count towards human intervention? Per claude: does number of replies not count toward human intervention?? ⏺ Yes they do! The oncall triage threshold is 50+ combined comments AND reactions, not just thumbs-up. Thank you for pointing that out.

Sorry, how many?

This should be reopened. The fix in v2.1.47 addressed Bugs 2 and 3 (picker limit 10->50, Windows case sensitivity), but Bug 1 - sessions-index.json not being updated for new sessions - is still unfixed as of v2.1.50.

On my machine: 68 .jsonl files on disk, only 25 were indexed. The 43 missing sessions span from early February onward - exactly matching the timeline described in the original report. I had to rebuild the index manually with a script.

The picker scanning .jsonl files directly (up to 50) is a good workaround, but the underlying index staleness is still there and will cause problems for users with more than 50 sessions per project.

Related open issue tracking the index staleness specifically: #25032

Still Broken — Custom Names Don't Show in Picker (Feb 23, 2026)

Bugs 2 and 3 may be fixed, but Bug 1 (index staleness) is NOT, and there's a 4th bug that was never addressed:

Custom session names (via /rename) display in terminal tab titles but NOT in the Ctrl+E/Ctrl+O resume picker. The picker shows auto-generated summaries instead.

Right now I have 6 open sessions with custom names ([bug manager], [1-min models], [shock features], etc.). Every single tab title shows the correct name. The resume picker shows none of them. I have to guess which session I'm opening every time.

This is day 5 of reporting this. Combined with the Bun crash epidemic on Windows (#21576 — 17 reproductions, 2 full computer lockups from orphaned processes), session management is completely non-functional:

• Can't keep sessions alive (Bun crashes every 1-3 hours)
• Can't find sessions when they survive (picker shows wrong names)
• Can't resume work after crashes (have to guess from 6 unnamed sessions)

This issue should be reopened. The partial fix in v2.1.47 didn't address the most user-facing problem.

Version: Claude Code latest, Bun v1.3.10, Windows 11

v2.1.50: Rename Bug Still Present

The v2.1.47 fixes addressed Bugs 2 and 3, but custom session names via /rename still don't appear in the resume picker. Tab titles show the correct names. Picker shows auto-generated summaries.

6 concurrent sessions affected on v2.1.50. This should be reopened — the partial fix did not address the most user-visible symptom.

Version: Claude Code v2.1.50, Bun v1.3.10, Windows 11

@ThatDragonOverThere You're right that this should be reopened — the v2.1.47 fix only addressed Bugs 2 and 3 while Bug 1 (index staleness) and your Bug 4 (/rename names invisible in picker) remain broken on v2.1.50. Unfortunately as the original author I can't reopen it — the repo restricts that to maintainers.

In lieu of reopening, I've filed a consolidated issue at #27242 that captures the full scope of session history inaccessibility. Your report compounds directly with what's tracked there:

| Layer | Problem | Where |
|-------|---------|-------|
| Find sessions | Index staleness — 68 files, 25 indexed | This issue, Bug 1 |
| Identify sessions | /rename names missing from picker | This issue, Bug 4 |
| Navigate branches | Right-arrow does nothing in picker | #27242 Bug 3 |
| View history | Pre-compaction content inaccessible | #27242 Bug 1 |
| Link plan sessions | No connection to predecessor session | #27242 Bug 2 |

The resume picker is the single gateway to all historical context and it's degraded at every level. If you're affected, please direct engagement (👍 + comments) to #27242 — that's where we're consolidating to hit the triage threshold.

+1 — Confirming on macOS, Claude Code v2.1.33

My sessions-index.json was created today for the first time (birth time = Feb 26 11:08). Before this, the resume picker showed all my sessions. Now it only shows ~10.

Stats:

• 94 .jsonl session files on disk
• Only 56 were indexed when the index was first generated
• 38 sessions completely invisible to the resume picker (including sessions from today)
• Resume picker search is broken — can't find sessions by keyword since it only searches the ~10 displayed

Workaround I used: Rebuilt the index manually with a Python script that scans all .jsonl files and re-indexes them. Sessions are all still intact on disk — just not in the index.

Version history:

• v2.1.19 (Jan 26) — resume picker worked fine, showed all sessions
• v2.1.32 → v2.1.33 (Feb 5) — behavior changed, sessions-index.json introduced
• Feb 26 — index auto-generated for first time, only captured 56/94 sessions

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.