claude-code - 💡(How to fix) Fix Add setting to filter /resume picker by current project directory [2 comments, 2 participants]

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)