[FEATURE] Sessions should follow a renamed/moved project folder (persistent project identity)

Preflight Checklist

• [x] I have searched existing requests — closest prior art is #55831 ("Allow renaming or moving a project folder while persisting history for sessions", closed not-planned Jun 2026) and #52494 (closed not-planned). No open issue covers this today, so re-raising with a concrete workflow.
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code identifies a "project" purely by its path-encoded working directory (~/.claude/projects/<encoded-path>/). When I rename or move a repo folder — a completely routine operation (I renamed ~/repos/myproject-old → ~/repos/myproject after a product rename) — every existing session is orphaned:

• The desktop app sidebar keeps showing the old folder as a project group, even though that folder no longer exists.
• Resuming any of those sessions fails ("folder is no longer available" in the desktop app; No conversation found with session ID in the CLI).
• Git worktree session folders under the old path are orphaned the same way.

There is no bulk migration path. The only recourse is per-session manual work.

Proposed Solution

Give projects a persistent identity that survives renames/moves, so sessions follow the folder. Possible shapes:

• A project ID file (e.g. .claude/project-id) written on first session, analogous to how .git/ makes a repo identity path-independent — the session store keys on the ID, with the path as a mutable attribute.
• Or: rename detection — when the app/CLI starts in a directory whose sessions dir doesn't exist, check for an existing project whose recorded path is gone and whose git remote / project-id matches, and offer a one-click "migrate N sessions to this folder".
• Or minimally: an explicit claude migrate-project <old-path> <new-path> command / desktop-app "move all sessions to another folder" action that does the bulk re-home safely.

Alternative Solutions

• The desktop app's per-session "change folder" action works but (a) it's one session at a time, (b) it creates a fork (a duplicate with a new session ID, "(fork)" suffix) rather than moving the session, and (c) session-scoped permission approvals don't carry over.
• Manually moving *.jsonl files between encoded directories under ~/.claude/projects/ works as a hack, but each JSONL also records its original cwd internally, so this is undocumented and fragile.
• /cd (v2.1.169+) only re-homes the active session, not historical ones.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. I have ~20 sessions of feature work in ~/repos/myproject-old, including sessions inside git worktrees.
2. The product is renamed, so I rename the folder to ~/repos/myproject, update the git remote, and fix all internal references. Git itself survives this fine (worktree links repairable with git worktree repair).
3. Claude Code, however, now shows a phantom myproject-old project in the sidebar; none of its sessions can be resumed in place.
4. With this feature, the sessions would simply appear under myproject and resume normally — matching what every user intuitively expects a folder rename to do.

Additional Context

• Environment: Claude Code 2.1.214, macOS (desktop app + CLI both affected).
• Prior reports: #52494, #55831, #61349, #27473, #33634, #37954, #48394 — this is a recurring pain point; the closures were "not planned" rather than "fixed", and the problem still reproduces on 2.1.214.
• Related but separate request (filed separately per the single-feature rule): graceful handling of sessions whose folder was deleted rather than renamed.