`/resume` picker hides sessions with mixed `cwd` history (after project directory rename/move)

Summary

The /resume / claude --resume picker rejects sessions whose JSONL history contains any entries with a cwd that differs from the current working directory — even when the most recent entries correctly reference the current cwd. This breaks resume for any long-running session that survived a project directory rename or move.

Direct resume by session ID (claude --resume <session-id>) works correctly, so the session data itself is fine — the bug is purely in the picker's filtering logic.

Use case affected

Any of these workflows will produce sessions with mixed cwd history and hit this bug:

• Renaming a project directory while continuing to work in the same session (e.g., mv ~/projects/foo ~/projects/bar, then cd ~/projects/bar && claude --resume)
• Moving a project to a new location and continuing an existing session
• Manually relocating a session JSONL file from one project directory to another and updating the current working directory to match
• Symlink/path changes where the resolved cwd ends up different after the fact

In all of these, the session remains fully valid and resumable by ID — but silently disappears from the picker list, which makes it look like the session was lost.

Reproduction

1. In a project directory ~/projects/oldname, start a Claude Code session with claude. Have a multi-turn conversation. Exit.
2. Rename the directory: mv ~/projects/oldname ~/projects/newname
3. cd ~/projects/newname && claude --resume <session-id> — resume the session directly. Work in it for a bit. Exit.
4. The session JSONL now contains both cwd values: older entries with ~/projects/oldname, newer entries with ~/projects/newname.
5. cd ~/projects/newname && claude --resume — session is missing from picker despite the most recent entries matching the current cwd.
6. claude --resume <session-id> — still works, confirming the session data is intact.

Evidence

In my project directory there are exactly two sessions, both stored in the same ~/.claude/projects/<encoded-cwd>/ directory:

| Session | cwd history | Shows in picker? |
|---------|--------------|------------------|
| A | single cwd (matches current) for all entries | ✅ yes |
| B | 235 entries with old cwd (project was renamed mid-session), 738 entries with current cwd | ❌ no |

Both sessions have the current cwd in their most recent entries. The only meaningful difference is session B's mixed history.

Fix that worked: rewriting all cwd entries in session B's JSONL to the new path (in-place with a Python script, preserving all other fields) made the session appear in the picker immediately. No other changes were needed.

Expected

The picker should either:

1. Match sessions based on the most recent cwd in each session (simplest fix — matches user expectation), or
2. Match if any entry in the session has a cwd matching the current directory, or
3. Rewrite old cwd entries to the new path on resume (so the file stays self-consistent going forward)

Option 1 is probably the cleanest — users care about where the session is now, not where it was at the moment a particular turn happened.

Related / not duplicates

• Possibly related: #41946 — same general symptom (valid session, not in picker, direct resume works) on version 2.1.45. User didn't find a structural difference, so their case may be a different trigger path for the same picker logic, or a separate bug.
• Not a duplicate of #46445 — that's the 2.1.101 regression where the picker defaults to showing sessions across all projects. Different bug.
• Not a duplicate of #43202 — that's about --resume <id> failing entirely after a directory rename. In my case direct resume works; only the picker display is affected.

Environment

• Claude Code: 2.1.101 (was 2.1.97 at time of last successful resume via picker; downgrading restores correct behavior for sessions the user can identify, but not for the picker view)
• OS: macOS 24.6.0 (Darwin)
• Shell: zsh