[BUG] sessions-index.json stops being updated after v2.1.31 — new sessions invisible to /resume
Status Fixed / completed
Reported on v2.1.31
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 11 comments · opened Feb 6, 2026 · closed Feb 17, 2026
Bug Description
After updating to Claude Code v2.1.31, new sessions are no longer being registered in sessions-index.json. Session .jsonl files are still being written to disk, but the index that /resume reads from stopped being updated. This makes all sessions created after the update invisible to /resume.
Reproduction Steps
- Update to Claude Code v2.1.31+ (confirmed on 2.1.31 through 2.1.34)
- Start a new session, do some work, exit
- Run
claudeand use/resumeto find the session - Session does not appear in the list
Diagnosis
# Count .jsonl session files vs indexed entries
PROJ_DIR=~/.claude/projects/<your-project-dir>
echo "JSONL files on disk: $(ls $PROJ_DIR/*.jsonl 2>/dev/null | wc -l)"
echo "Entries in index: $(python3 -c "import json; print(len(json.load(open('$PROJ_DIR/sessions-index.json'))['entries']))")"
echo "Index last modified: $(stat -f '%Sm' -t '%Y-%m-%d %H:%M' $PROJ_DIR/sessions-index.json)"
In my case:
- 98
.jsonlfiles on disk - 37 entries in
sessions-index.json - 6 real sessions created after Feb 4 are not indexed (the rest of the gap is agent sub-sessions, file-history snapshots, etc. that were never meant to be indexed)
- Index was last modified 2026-02-04 09:09 — the day v2.1.31 was installed
- The newest indexed session is from 2026-02-03
Workaround
If you know the session ID (from the .jsonl filename), you can still resume directly:
claude --resume <session-id>
But browsing/searching via /resume won't show any session created after the index stopped updating.
Environment
- Claude Code versions: 2.1.31, 2.1.32, 2.1.33, 2.1.34 (all affected)
- Last working version: Unknown, but index has entries up to 2026-02-03 (likely 2.1.30 or earlier)
- Platform: macOS Darwin 25.2.0
- Node: v22.22.0
Related Issues
- #22030 — similar symptom (stale
sessions-index.json) but different root cause (metadata drift vs index not being written at all) - #14157 — similar pattern of
/resumeregression after version update - #18311 — sessions exist on disk but not discoverable
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Update: sessions-index.json is not used by /resume at all in v2.1.34
After further investigation, the issue is different (and bigger) than initially reported.
What we tried
sessions-index.jsonto force a rebuild — Claude Code regenerated it but only with ~0 entries/resumestill only showed ~5 recent sessions — proving it doesn't read fromsessions-index.jsonat allActual behavior in v2.1.34
The
/resumesession picker appears to scan.jsonlfiles by recency and only displays the most recent ~5 sessions. It does not read fromsessions-index.json.This means:
sessions-index.jsonappears to be vestigial — written to but never read from by the pickerclaude --resume <id>Ctrl+A("show all projects") in the picker does not reveal additional sessionsPreviously (before ~v2.1.31)
The
/resumepicker showed all sessions including those from git worktrees. Users could browse and search through their full session history.Impact
For users with many sessions across worktrees (in our case 119+ sessions across 28 project directories), this is a significant regression in discoverability. The only workaround is manually tracking session IDs.
Workaround: auto-repair via SessionStart hook
Same issue confirmed on Windows 11 (CC 2.1.34) — 25 of 95 sessions indexed. See #23614 for the full root cause analysis.
Built a repair script + SessionStart hook that auto-fixes this on every CC launch:
Repair script (
repair-sessions-index.py)<details>
<summary>Click to expand full script (~250 lines)</summary>
</details>
Usage
Auto-fix via SessionStart hook
Add to your
~/.claude/settings.jsonto auto-repair on every CC launch:The
--hookflag consumes stdin, auto-fixes silently, and outputs{"continue":true,"suppressOutput":true}. Only prints to stderr when repairs are made. Index is repaired before your prompt appears — so--resumealways works against a current index.Note from #23614: In v2.1.34, the
/resumepicker may scan.jsonlfiles by recency instead of readingsessions-index.json. The index repair still helps forclaude --resume "name"(CLI flag) which matches againstcustomTitle.Confirming:
sessions-index.jsonis completely unused by/resumein v2.1.31+@Sajakhtar's finding is correct. After reverse-engineering the minified
cli.js(v2.1.39), I can confirm the full mechanism:How
/resumeactually loads sessionsdd1(projectDir)— callsreaddirSyncon the project directory, filters for UUID-named.jsonlfiles,stats each one for mtime/ctime/sizePf1— sorts by mtime descending, creates "lite" entries (no content loaded yet)MY1— iterates through sorted entries, callsjwz→Xwzto lazily read the first 16KB (forfirstPrompt,isSidechain,teamName) and last 16KB (forcustomTitle,tag,gitBranch) of each.jsonlfilefirstPromptAND nocustomTitle, or ifisSidechain/teamNameis setsessions-index.jsonis never read. The string doesn't even appear in the source.The real bug is pagination
The picker loads only 10 sessions initially (hardcoded in
MY1). More should load viaonLoadMorewhen scrolling, but the load-more trigger depends on terminal height and highlight position interacting correctly:With small terminals (24 rows → page_size=4), the load-more effect doesn't reliably fire because the Ink SelectInput wraps at the list boundary instead of pushing the highlight position high enough. See my detailed analysis on #24435.
Workaround
claude --resume <keyword>bypasses the picker entirely and searches all session files on disk directly. This works reliably regardless of terminal size.Rebuilding
sessions-index.json(as many of us tried) has no effect on/resumebehavior.Update: Published the repair script and SessionStart hook as part of my open-source Claude Code configuration:
Repo: bosmadev/claude
scripts/repair-sessions-index.py— finds orphaned.jsonlsession files and re-indexes themhooks/transaction.py) for safe concurrent writes with OCCNote: per @tracymelody's finding above,
/resumein v2.1.31+ reads.jsonlfiles directly from disk (readdirSync) rather than relying onsessions-index.json. The index file may only matter for theclaude -cflag and older versions. The repair script still helps for tooling that reads the index (status line,/chatsskill, etc).@claude please prioritise this issue, not having access to session history is a critical bug
This issue is tracked in the consolidated report at #26123, which identifies 3 distinct root causes (index writes stopped Feb 4, picker hardcoded to 10-session batch, Windows worktree case-sensitivity) with source-level analysis and a one-line fix. Please add your thumbs-up there to help it reach the oncall triage threshold.
Your 👍 on the consolidated issue matters. Based on how this repo's automated triage works, issues need 50+ combined reactions and comments to trigger the oncall label — the only way a human at Anthropic actually reviews it. Right now the engagement is split across 12+ duplicate issues and none will ever hit that threshold alone.
The consolidated issue with full root cause analysis (3 bugs identified, one-line fix included) is here: #26123
Please go add your 👍 there. That's the single most useful thing you can do to get this fixed.
closing since this is consolidated into https://github.com/anthropics/claude-code/issues/26123
We're at 22 👍 on the consolidated issue — more than halfway to the 50 needed to get a human at Anthropic to look at this. Every thumbs-up on a duplicate issue is a thumbs-up that doesn't count. The automated triage bot only checks individual issues, not the cluster.
Please take 5 seconds to 👍 here: #26123
The root causes are fully identified, a one-line fix exists, and community repair scripts are available. The only thing missing is enough engagement on a single issue to cross the oncall threshold. We can get this fixed if we stop splitting our votes across 12 separate reports.
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.