[FEATURE] Allow /resume and --resume to display full session history (not limited to 10)

Resolved 💬 8 comments Opened Feb 12, 2026 by poka-IT Closed Apr 3, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

The /resume command (and claude --resume CLI flag) only displays the 10 most recent sessions, even when dozens of sessions exist in ~/.claude/projects/. This makes it effectively impossible to navigate back to older sessions through the built-in UI.

This was previously raised in #2333, which was auto-closed as "not planned" without any official response or explanation from the team. The issue is still very much relevant and impacts daily workflows.

As a developer working on long-running projects, I frequently need to revisit sessions from days or weeks ago. whether to recover context from a past debugging session, reference a previous architectural decision, or resume work that was paused. Being limited to only the 10 most recent sessions forces me to either:

  1. Manually dig through ~/.claude/projects/ to find session IDs
  2. Lose access to valuable session history entirely
  3. Use workarounds like grepping JSON files in the sessions directory

The built-in search in the resume picker helps somewhat, but it only searches within the 10 displayed sessions, not across the full history.

Proposed Solution

I'd like the /resume picker (and claude --resume) to provide access to the complete session history, not just the last 10. This could be implemented in several ways:

  • Increase or remove the hard limit: Show all available sessions (or at least 50+), with the existing search to filter them.
  • Add a --limit flag: Allow claude --resume --limit 50 or claude --resume --all to control how many sessions are displayed.
  • Add a configurable setting: Allow users to set resumeSessionLimit in ~/.claude.json or .claude/settings.json to define their preferred limit.
  • Implement pagination: Add a "Load more" option at the bottom of the session list to progressively load older sessions.

Alternative Solutions

  • Manual session ID lookup: Currently I work around this by running ls -lt ~/.claude/projects/*/ to find older session directories, then using claude --resume <session-id> directly. This is cumbersome and defeats the purpose of having an interactive picker.
  • External scripting: Writing shell scripts to parse session metadata and present a custom picker using fzf or similar tools. This works but shouldn't be necessary for a core feature.
  • Naming sessions proactively: Using /rename on every session to make them easier to find later. This adds friction and doesn't solve the fundamental discoverability problem for unnamed sessions.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Concrete scenario:

  1. I'm working on a complex project with Claude Code as my primary AI coding assistant
  2. Over the course of a week, I accumulate 30+ sessions across different features, bug fixes, and explorations
  3. On Friday, I need to revisit a debugging session from Monday where Claude and I identified a root cause for a tricky issue
  4. I run /resume, but that Monday session is nowhere in the list, buried beyond the 10-session limit
  5. I have to manually browse ~/.claude/projects/ directories, open JSON files to check conversation content, find the right session ID, and paste it into claude --resume <id>
  6. With full history access, I could simply scroll or search through all sessions and resume instantly

Additional Context

  • Related issue: #23313 was closed without resolution by auto-close bot, not by a maintainer decision
  • Version: Tested on Claude Code v2.1.39, issue persists since at least v1.x
  • Sessions are already stored locally: The data is already there in ~/.claude/projects/, the picker simply doesn't expose it
  • No technical limitation: This appears to be a UI-level cap, not a storage or performance constraint, loading session metadata for even hundreds of sessions should be nearly instantaneous

View original on GitHub ↗

This issue has 8 comments on GitHub. Read the full discussion on GitHub ↗