Add setting to filter /resume picker by current project directory

Resolved 💬 3 comments Opened Apr 12, 2026 by zoharbabin Closed Apr 12, 2026

Summary

The /resume and --resume picker now shows sessions from all projects by default. This was changed intentionally in v2.1.101 (fixing what was described as a "narrow default view hiding sessions from other projects"). While cross-project visibility is useful in some workflows, many users rely on per-directory session isolation and find the new default noisy — especially when working across many projects.

Request: Add a user setting (e.g. resume.filterByCurrentProject: true) to restore per-directory filtering as the default view in the /resume picker.

Context

Prior to v2.1.101, /resume only showed conversations from the current working directory's project. The fix in v2.1.101 widened this to all projects, and v2.1.97–98 added filter hint labels (project/worktree/branch) to compensate.

The problem is that the picker now requires manual filtering every time to get back to the old behavior. For users who work across 10–20+ projects (as reflected in ~/.claude/projects/), the unfiltered list is cluttered with irrelevant sessions from other repos.

Proposed Solution

Add a boolean setting in settings.json, e.g.:

{
  "resume": {
    "filterByCurrentProject": true
  }
}

When true, the /resume picker defaults to showing only sessions from the current project directory (the pre-v2.1.101 behavior). Users can still toggle the filter off in the picker to see all sessions when needed.

When false (the default), behavior stays as it is today — all sessions shown, filterable via the existing hint labels.

Why This Matters

  • Muscle memory: Long-time users expect /resume to show only relevant sessions for the repo they're in. The new default breaks that expectation silently.
  • Signal-to-noise: Users with many projects see dozens of unrelated sessions, making it harder to find the one they want.
  • --continue is not a substitute: -c only resumes the most recent session — it doesn't let you pick from a filtered list.
  • Low cost to implement: The project-level filtering logic already exists (it was the old default), and the filter UI infrastructure is already in place from v2.1.97–98.

Environment

  • Claude Code version: 2.1.104
  • Platform: macOS (Darwin 25.3.0)

View original on GitHub ↗

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