Resume picker only shows ~8 most recent sessions, older sessions not resumable

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23375
2. https://github.com/anthropics/claude-code/issues/23072
3. https://github.com/anthropics/claude-code/issues/23933

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 analysis from source reverse-engineering (v2.1.39)

Spent some time tracing through the minified cli.js to find the exact mechanism. Here's what's happening:

1. sessions-index.json is not used

Despite what many reports assume, /resume in v2.1.31+ does not read sessions-index.json. The dd1 function scans the project directory with readdirSync, filters for UUID-named .jsonl files, and stats each one. Session metadata is extracted lazily by reading the first/last 16KB of each file (Xwz function).

2. Initial batch is hardcoded to 10

MY1(allStatLogs, 0, K=10) loads the first 10 visible sessions. Further sessions are supposed to load via an onLoadMore callback when the user scrolls near the end of the list.

3. Load-more trigger depends on terminal height

The page size is calculated as:

gz = Math.max(1, Math.floor((terminal_rows - ~10) / 3))

Each session entry takes ~3 rows in the picker. With a typical 24-row terminal, gz = 4 (only 4 items visible at a time).

The load-more fires via a useEffect when:

highlighted_position + (gz * 2) >= loaded_count

With gz=4 and 10 loaded items, you need position + 8 >= 10, so highlighting item 3+ should trigger it. However, the Ink SelectInput wraps at the list boundary (item 10 → item 1), and the filter pipeline (C7z, projectPath filter, branch filter) can transiently reduce the list length, causing the effect dependencies to not re-fire correctly.

4. The C7z filter can discard "lite" sessions

Before sessions are lazily loaded with full metadata, they're marked isLite: true with empty firstPrompt/customTitle. The C7z filter returns false for these, which can reduce the visible list below gz, hiding the "(X of Y)" counter and making the component behave as if all sessions are loaded.

Workaround

claude --resume <keyword> bypasses the picker UI entirely and searches all sessions on disk. This works correctly even when the /resume interactive picker fails to show them.

Environment

• macOS, Claude Code v2.1.39
• Terminal: 24 rows
• 32 session files in project directory, 24 with content — picker shows ~10 then wraps

Fix: Patch the batch size in cli.js

The root cause is that /resume loads only 10 sessions initially and the load-more pagination is broken. The simplest fix is to increase the batch size so all sessions load at once.

One-liner patch

CLI_JS="$(dirname "$(readlink "$(which claude)")")/../lib/node_modules/@anthropic-ai/claude-code/cli.js"
cp "$CLI_JS" "$CLI_JS.bak"
sed -i '' \
  -e 's/async function _c1(A,q,K=10)/async function _c1(A,q,K=500)/' \
  -e 's/function mN6(A,q,K=10)/function mN6(A,q,K=500)/' \
  -e 's/async function lT6(A,q=10)/async function lT6(A,q=500)/' \
  "$CLI_JS"

On Linux, use sed -i instead of sed -i ''.

This changes the initial batch from 10 → 500 in the three session-loading functions (_c1, mN6, lT6). The picker then loads all sessions upfront instead of relying on the broken scroll-to-load-more logic.

What it fixes

• /resume now shows all sessions instead of ~10
• "Show all projects" toggle also loads all sessions
• claude --resume <keyword> already worked — this fixes the interactive picker

Caveats

• Overwritten on every claude update — re-run after updating
• Minor increase in picker open time if you have hundreds of sessions (each file's first+last 16KB is read), negligible for <100 sessions
• To undo: cp "$CLI_JS.bak" "$CLI_JS"

Suggestion for Anthropic

Consider making this a configurable setting (e.g., resumeBatchSize in settings.json) or simply increasing the default. 10 is too low for anyone who uses Claude Code regularly. Alternatively, fix the useEffect load-more trigger so it fires reliably regardless of terminal height.

Confirmed on v2.1.39 (macOS, compiled Mach-O binary).

The limit is hardcoded as a default parameter A=10 in two functions in the bundled source:

async function ewR(T, R, A=10) { return (await ZpT(T, R, A)).logs }
async function ZpT(T, R, A=10) { / calls A1T(_, 0, A) / }

These control how many sessions are loaded for the picker. Found at offset ~69288748 in the binary.

Attempted a binary patch (A=10 → A=99) but macOS code signing rejects the modified binary (zsh: killed), so there's no viable user-side workaround beyond claude --resume <session-id> or using / search in the picker.

Request: Make this configurable (e.g., a resumeLimit setting) or raise the default significantly. 10 is too low for active projects — my project directory has 434 session files.

Yet another error for my rapidly growing list of reasons this tool is becoming hard to justify in a paid workflow:

• Claude will revert commits without asking and happily discard uncommitted changes. Then it informs you after the fact with something along the lines of: “Your uncommitted changes were lost; you’ll have to redo them. Good luck with that.”
• Claude will wander into train-of-thought dead ends and effectively burn the customer’s entire approved balance down to $0 with no usable output, instead of detecting that it’s stuck and stopping to ask whether to continue.
• Claude tends to create corrupt nul files in Windows due to some ill-management of the filesystem.
• Claude will cut off responses mid-edit when tokens run out, leaving your code in a broken/unbuildable state and essentially saying: “See you in 6 hours. Good luck fixing your now-broken code.”
• Claude is painfully slow on trivial tasks that Copilot finishes in seconds—Claude takes minutes, consuming far more tokens in the process.

At this point it’s less “AI assistant” and more “surprise-cost generator with a side of repository vandalism.”

I would really appreciate removing the limit of 10 most recent by default and going back to being able to search all previous conversations in the project.

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.

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.