Sessions-index.json: summaries not generated and new sessions not indexed since ~v2.1.31

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23614
2. https://github.com/anthropics/claude-code/issues/23421
3. https://github.com/anthropics/claude-code/issues/22878

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

Root Cause Found

After reverse-engineering the minified cli.js, the actual root cause is a case-sensitivity bug in the multi-worktree code path of the /resume command.

The Bug

In function xa (conversation loader), when git worktree list returns >1 worktree, the code takes a multi-worktree path:

// xa function (deobfuscated)
let sanitizedPaths = worktreePaths.map(p => p.replace(/[^a-zA-Z0-9]/g, "-"));
let projectDirs = fs.readdirSync(projectsDir);
for (let dir of projectDirs) {
    if (sanitizedPaths.some(s => dir.name === s || dir.name.startsWith(s + "-")))
        matchedDirs.push(dir);
}

The comparison dir.name === s is case-sensitive. On Windows:

• git worktree list returns C:/TrinityBots/TrinityCore (uppercase drive letter)
• GYA("C:/...") produces C--TrinityBots-TrinityCore
• But the project directory on disk is c--TrinityBots-TrinityCore (lowercase, from when it was originally created)
• "c--TrinityBots-TrinityCore" === "C--TrinityBots-TrinityCore" → false
• Result: 0 sessions found

Why It Only Broke Recently

Before ~Feb 2, there was only 1 git worktree. The code has a fast path: if (worktrees.length <= 1) that calls ZX(A8()) directly (uses the current working directory, not git worktree output). This path worked correctly.

When a tool (zenflow) created additional worktrees, git worktree list returned 6 entries, triggering the multi-worktree code path with the case-sensitive comparison bug.

Fix

The comparison in xa should be case-insensitive on Windows:

// Fix: case-insensitive comparison
let dirLower = dir.name.toLowerCase();
if (sanitizedPaths.some(s => dirLower === s.toLowerCase() || dirLower.startsWith(s.toLowerCase() + "-")))

Workaround

Remove stale git worktrees: git worktree remove <path> until only 1 worktree remains, which triggers the working single-worktree fast path.

Confirmed on macOS - Not Windows-Specific

While the worktree case-sensitivity bug you found is real, there's a broader system-wide issue affecting all platforms:

Cross-Platform Evidence

macOS user here - same symptoms without multiple worktrees:

• Last indexed session: Feb 4, 2026, 00:33 UTC (across all projects)
• Total session files: 3,080+ .jsonl files on disk
• Sessions indexed: 740 (24% of total)
• Sessions after Feb 4: 0% indexed

This matches the other report in #25032 (also macOS, same Feb 4 cutoff).

Two Distinct Issues

1. System-wide indexing failure (affects everyone, all platforms)

• Session indexing stopped: Feb 4, 2026, 00:33 UTC
• Summary generation degraded: late January

1. Windows worktree case-sensitivity bug (Windows-only, masks issue #1)

• Your reverse-engineering of the xa function is correct
• But this only affects Windows users with >1 worktree
• The underlying indexing failure affects everyone

Empty Summaries

The empty summaries you observed ("summary": "") also appear on macOS:

• Some projects: 26% empty summaries
• Other projects: 82% empty summaries

These started appearing in late January, before indexing stopped entirely on Feb 4.

Potential Root Cause: Connection to #16157

The timeline aligns with the usage quota crisis (#16157):

Timeline:

• Jan 3: #16157 opened - users hitting limits 5-10x faster
• Jan 19-26: Anthropic "rolled out changes to reduce token usage" (comment)
• Late January: Session summaries become empty (no API calls = no token cost)
• Feb 4, 00:33 UTC: Session indexing stops completely
• Feb 10-11: Users discover and report (#24729, #25032)

Session summary generation costs tokens:

• Input: Session transcript (100K+ tokens)
• Output: Summary text (~100-500 tokens)
• Cost: Multiplied by every session, every user

Disabling automatic summarization and indexing would immediately reduce token consumption across the platform - a logical emergency response to #16157, whether intentional or not.

Recommendation

The worktree bug should still be fixed, but the broader indexing failure is the more urgent issue as it affects all users. Both issues need Anthropic's attention.

Confirming — Stale Session List (Feb 10, 2026)

Version: Bun Canary v1.3.9-canary.51 (d5628db2), Windows 11, PowerShell
Claude Code: Opus 4.6

Reproduction

1. Had multiple active sessions running throughout the day (long ML pipeline work)
2. Restarted a new terminal window
3. Pressed Ctrl+E / Ctrl+O to view prior transcripts
4. Conversation list was hours old — recent sessions not listed
5. No error displayed, just stale data

Notes

• This is on Windows (non-WSL, non-worktree setup — single project directory)
• Confirms @genesiscz's report that this is not Windows-specific and not limited to the worktree code path
• The sessions-index.json simply isn't being updated when new sessions are created or existing ones grow

Matches the broader pattern: new sessions since ~v2.1.31 not being indexed.

Second Occurrence — Feb 14, 2026

Same bug, same environment. Restarted a new CLI window, pressed Ctrl+E to resume a recent session — the conversation list was hours behind again. Recent sessions from today's work completely missing from the picker.

Version: Bun Canary v1.3.9-canary.51 (d5628db2), Windows 11, PowerShell, Opus 4.6

This is now the 2nd time in 4 days. The session index is simply not being written to as new sessions are created or updated.

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.

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.

Possible Root Cause: v2.1.30 Session Index Replacement

From the CHANGELOG.md, version 2.1.30 includes:

"Improved memory usage for --resume (68% reduction for users with many sessions) by replacing the session index with lightweight stat-based loading and progressive enrichment"

This correlates with when sessions stopped being indexed. @genesiscz reported their last indexed session was Feb 4, 2026 — right around when 2.1.30 shipped. The "lightweight stat-based loading" replacement appears to have broken session discovery for Ctrl+E/Ctrl+O.

The old sessions-index.json approach explicitly tracked sessions. The new "stat-based loading" approach apparently doesn't reliably detect new or updated sessions, resulting in stale conversation lists that are hours (or days) behind.

@agatho already found a case-sensitivity bug in the worktree code path, but this changelog entry suggests the issue is broader — the entire indexing mechanism was swapped out in 2.1.30 and the replacement doesn't work correctly.

Still Broken — Feb 23, 2026

Session resume list (Ctrl+E/Ctrl+O) still shows stale data. 6 active sessions with custom names visible in tab titles but not in the picker. Names persist in storage but the session indexer/picker doesn't read them back.

Combined with the Bun crash epidemic (#21576 — 17 repros, 2 computer lockups), session management on Windows is completely broken. Can't keep sessions alive (Bun crashes), can't find them when they survive (picker shows wrong names).

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

Still Broken in v2.1.50 — Feb 23, 2026

The v2.1.30 session index replacement and v2.1.47 picker limit increase (10→50) did NOT fully resolve this.

Custom session names set via /rename display correctly in terminal tab titles but NOT in the Ctrl+E/Ctrl+O resume picker. 6 concurrent sessions affected. The picker shows auto-generated summaries instead of custom names.

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

v2.1.55 Update: Still Broken, Plus New Blank Resume Bug

Session indexing is still broken in v2.1.55 (regressed from v2.1.53 fix, documented on #25090).

New related issue: #28577 — session resume now loads completely blank. 4.5 MB JSONL file intact on disk, picker shows it, selecting loads nothing. This is the 4th layer of Windows session management failure:

1. Bun crashes force constant resumes (#21576 — 26+ crashes)
2. Session names don't show in picker (this issue + #25090)
3. Bash tool was broken, couldn't even work (#28343, fixed in v2.1.55)
4. Resume loads blank (#28577 — NEW)

At this point, resuming a session on Windows is essentially gambling.

Regression in v2.1.79 — /rename broken again

Cross-referencing from #25090. /rename (session naming) is broken again as of v2.1.79.

This issue was closed after the fix in v2.1.75/v2.1.76 was confirmed working by the reporter. The same symptom — session names not persisting — has returned 3 versions later.

Platform: Windows 11, CLI
Working version: v2.1.76 (confirmed fixed)
Broken version: v2.1.79 (regression)

Please reopen — something in v2.1.77–v2.1.79 re-introduced this bug.

Still experiencing this on v2.1.83 (Windows/WSL2).

Setup: 19 top-level session .jsonl files in the project directory, 719 subagent .jsonl files in subdirectories.

Symptoms:

• claude --resume shows only 2 conversations out of 19
• No sessions-index.json exists for the project (never created)
• Manually deleting sessions-index.json from other projects did not trigger regeneration — the file is simply never recreated
• claude --continue works fine (reads most recent .jsonl directly)
• Resuming by session ID (claude --resume <uuid>) works as a workaround

Diagnostic details:

• 8 of 19 project directories had a sessions-index.json; the rest (including the active project) never had one
• All session .jsonl files have valid structure and are non-empty
• Sessions span versions 2.1.79 through 2.1.83 — none are indexed

This has been persistent across multiple versions. Would love to see a fix or at minimum a --resume fallback that scans .jsonl files directly when the index is missing/stale.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

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.