`claude -r <session-name>` fails to find sessions renamed via `/rename` — session lookup unreliable

Description

Sessions renamed via /rename inside Claude Code cannot be reliably resumed with claude -r <session-name>. The Resume Session picker renders with the session name pre-filled in the search box but no matching sessions are listed — even though the session exists and was renamed in the same version.

This is especially problematic because Claude Code itself suggests claude -r <session-name> on session exit, directing users into this broken flow.

The bug is flaky/intermittent — the same named session sometimes resumes successfully, sometimes shows zero results. Special characters in session names (dashes -, underscores _) may be involved, but the intermittent nature makes this hard to confirm without systematic testing (e.g., fuzzing session names).

Steps to Reproduce

1. Start a Claude Code session in a project directory
2. Rename the session using /rename (e.g., to my-dev-supervisor)
3. Verify the new name appears in the top-right of the prompt box
4. Exit the session — Claude suggests resuming with claude -r my-dev-supervisor
5. Run claude -r my-dev-supervisor
6. Intermittently: the Resume Session picker opens with the name pre-filled but shows no matching sessions and becomes frozen

Expected Behavior

claude -r <session-name> should reliably resume a session that was renamed via /rename, especially when Claude itself recommends this exact command on exit.

If the session cannot be found, the picker should:

• Display a clear "No matching sessions found" message
• Remain responsive (Enter should exit or offer alternatives, not silently do nothing)

Actual Behavior

• The picker renders with the search term but no sessions listed (just "current worktree" label)
• Sometimes: the picker remains responsive — Escape and double Ctrl+C dismiss it, but Enter does nothing (no session to select)
• Sometimes: the picker fully freezes — no input (Enter, Escape, Ctrl+C, arrows) has any effect; the process must be killed externally
• No error message or "no results found" indication in either case

Observed symptoms (both flaky)

1. Session not found: The picker renders with the session name in the search box but no matching sessions are listed — only "current worktree" label is visible. A session renamed via /rename (confirmed in the UI) is not found by the picker's search.

2. Picker freeze (intermittent): On some attempts, the picker becomes completely unresponsive — Enter, Escape, Ctrl+C, arrow keys, typing all have no effect. The only way out is to kill the process externally (e.g., via tmux send-keys). On other attempts with the same session name, the picker is merely empty but still responsive to Escape and double Ctrl+C.

Both symptoms are flaky — the same claude -r <name> command on the same session sometimes finds the session, sometimes shows empty results, and sometimes fully freezes. This makes the bug difficult to reproduce deterministically and suggests multiple interacting issues (index lookup timing + possible TUI rendering race).

Environment

• Claude Code version: 2.1.49
• OS: Linux (Arch)
• Terminal: tmux 3.5a (Konsole host)
• TERM: xterm-256color
• Node.js: v22.19.0

Additional Context

• Session names tested contained dashes (-) and underscores (_) — these may affect search/matching behavior
• The project had 2000+ session files across all projects, which may contribute to index lookup timing issues
• The sessions-index.json for the affected project had valid entries but the renamed session's custom title was not found in the index at the time of investigation
• The flaky nature suggests this could benefit from systematic fuzzing of session names with various special characters and concurrent index access patterns

Why this is not a duplicate

This issue has been checked against all existing resume/freeze issues and is distinct from each:

| Issue | What it reports | How this differs |
|-------|----------------|------------------|
| #23933 | Named sessions from older versions not resumable after upgrade | Here the session was created, renamed via /rename, and resume attempted all in the same version (2.1.49). No version migration involved. |
| #22227 | Picker never renders at all — CLI hangs with blank output (tmux+Alacritty) | Here the picker does render correctly, shows the search box with the term, but becomes unresponsive when zero results are returned. The TUI is visible but frozen. |
| #19041 | FSWatcher handles leak, preventing Ctrl+D exit | Different symptom — here Escape works to dismiss. The issue is that Enter/arrows/typing are silently ignored when no sessions match. |
| #21067, #19199, #22149 | Resume hangs due to large session files (multi-MB JSONL, uncompacted progress events) | Here the issue is not about session file size or parsing — it's about the name lookup failing for a /renamed session. The session may be small. |
| #22190, #19569 | Version-specific regressions in resume (2.1.27, 2.1.12) | Those were fixed in subsequent releases. This is on current 2.1.49. |
| #24169, #24394 | Windows-specific input freeze on resume | This is Linux. |

What makes this issue unique:

1. /rename ➜ resume round-trip is broken. The specific flow of: rename session via /rename → Claude confirms the name in UI → Claude suggests claude -r <name> on exit → user follows that suggestion → lookup fails — is not reported elsewhere. This is a first-party recommended workflow that is unreliable.

1. Intermittent/flaky nature. Unlike #23933 (consistently broken for old sessions) or #22227 (consistently blank), this is a heisenbug — the same session name sometimes resumes, sometimes doesn't. This points to a race condition or timing-dependent index issue, not a format incompatibility.

1. Picker renders but intermittently freezes completely. #22227 reports the picker never rendering at all (blank hang). Here the picker visually renders (search box, hotkey hints visible) but intermittently becomes fully unresponsive — no input works, must be killed externally. On other attempts the same picker is dismissible. This intermittent freeze-vs-responsive behavior on the same command is not described in any existing issue.