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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   platform:macosIssue specifically occurs on macOSIssue specifically occurs on macOS

   area:tui

   on Feb 9, 2026
2. github-actions commented on Feb 9, 2026

   

   github-actionsBot

   on Feb 9, 2026 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. [BUG] /resume only shows a few recent conversations, most sessions missing from picker #23375
   2. [BUG] Not able to --continue sessions with large .jsonl files. Those sessions are also dropped from --resume overview #23072
   3. Named sessions from older versions not resumable in v2.1.x #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

   👎React with 👎3Reacted by Maksim Potanin, slurpit and XieRan.sai
3. tracymelody commented on Feb 11, 2026

   

   tracymelody

   on Feb 11, 2026

   More actions

   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
4. tracymelody commented on Feb 11, 2026

   

   tracymelody

   on Feb 11, 2026

   More actions

   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.
5. gilbert-umuzi commented on Feb 12, 2026

   

   gilbert-umuzi

   on Feb 12, 2026

   More actions

   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 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.

   👍React with 👍1Reacted by Andrés Zsögön

   😕React with 😕1Reacted by Andrés Zsögön
6. andreszs commented on Feb 14, 2026

   

   andreszs

   on Feb 14, 2026

   More actions

   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.”
7. eon-dev1 commented on Feb 14, 2026

   

   eon-dev1

   on Feb 14, 2026

   More actions

   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.

   👍React with 👍2Reacted by Andrés Zsögön and Dorian Villet
8. scapeshift-ojones commented on Feb 16, 2026

   

   scapeshift-ojones

   on Feb 16, 2026

   More actions

   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.
9. scapeshift-ojones commented on Feb 16, 2026

   

   scapeshift-ojones

   on Feb 16, 2026

   More actions

   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.
10. scapeshift-ojones commented on Feb 17, 2026

    

    scapeshift-ojones

    on Feb 17, 2026

    More actions

    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.

    👍React with 👍1Reacted by Andrés Zsögön
11. github-actions

    added

    staleIssue is inactiveIssue is inactive

    on Mar 3, 2026
12. github-actions commented on Mar 17, 2026

    

    github-actionsBot

    on Mar 17, 2026 – with GitHub Actions

    More actions

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

    closed this as not plannedon Mar 17, 2026
14. github-actions commented on Mar 26, 2026

    

    github-actionsBot

    on Mar 26, 2026 – with GitHub Actions

    More actions

    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.
15. github-actions

    locked as resolved and limited conversation to collaborators on Mar 26, 2026