[BUG] Desktop: sessions from a folder whose path is a string prefix of a sibling (MyApp vs MyApp-MR) are grouped under the shorter project and resume against the wrong folder

Summary

In the Claude Desktop app (Code tab), sessions belonging to a project folder whose path is a string prefix of a sibling folder's path get grouped under the shorter-named project, and resuming one of them targets the wrong folder.

Layout that triggers it — two independent clones, different branches, different working state:

~/projects/MyApp        <- branch A
~/projects/MyApp-MR     <- branch B

~/projects/MyApp is an exact string prefix of ~/projects/MyApp-MR.

Expected

Sessions opened in ~/projects/MyApp-MR stay grouped under a MyApp-MR project, and resuming one opens with MyApp-MR as the primary working directory.

Actual

Sessions were opened and worked in ~/projects/MyApp-MR one day. On returning the next day:

1. They appeared grouped under the MyApp project in the sidebar, not MyApp-MR.
2. They pointed at the ~/projects/MyApp folder — a different branch with different working-tree state.

This is the dangerous part: the two folders are different checkouts of the same repo, so a resumed session looks plausible while reading and potentially editing the wrong tree. Nothing in the UI flagged the switch.

Evidence: the persisted data is correct, so this is display/resolution-layer

I inspected the on-disk state after the fact. All of it is correctly separated:

• Two distinct transcript directories exist and are correctly populated: ~/.claude/projects/-Users-me-projects-MyApp-MR/ and ~/.claude/projects/-Users-me-projects-MyApp/.
• Every "cwd" field in every -MyApp-MR transcript is /Users/me/projects/MyApp-MR. No entry points at the other folder. The reverse also holds.
• No cross-writes between the two sets of transcripts. One -MyApp-MR file had a later mtime than its last prompt, but the appended lines were only {"type":"custom-title"} and {"type":"mode"} metadata.
• ~/.claude.json has both /Users/me/projects/MyApp and /Users/me/projects/MyApp-MR as separate projects keys.
• The app's own session index reports the correct cwd for all six -MR sessions.

So the grouping shown in the sidebar disagreed with every persisted record of these sessions' working directory.

Suspected cause

A path comparison somewhere in project grouping / cwd resolution that uses a plain prefix test without requiring a trailing path separator — e.g. path.startsWith(projectPath) rather than path === projectPath || path.startsWith(projectPath + sep).

Under that logic /Users/me/projects/MyApp-MR matches the /Users/me/projects/MyApp project, and the group's folder resolves to the shorter path. That accounts for both symptoms at once (wrong group and wrong target folder) and for the persisted data being untouched.

The same hazard applies to the encoded directory keys, where -Users-me-projects-MyApp is a prefix of -Users-me-projects-MyApp-MR.

Reproduction

1. Create two sibling folders where one name is a prefix of the other: ~/projects/MyApp and ~/projects/MyApp-MR. Git clones on different branches make the consequence visible.
2. Open sessions in the Desktop app against both folders, so both project groups exist.
3. Have some conversations in the MyApp-MR sessions.
4. Quit and reopen the app the next day.
5. Observe which project group the MyApp-MR sessions appear under, and which folder they resolve to on resume.

I hit this after an app restart with a day in between, so it may depend on how groups are rebuilt at startup rather than reproducing on every launch.

Impact

Real risk of reads and edits landing in the wrong checkout of the same repository, silently. foo / foo-MR, foo / foo-old, foo / foo-2, api / api-v2 are all common conventions for exactly the case where you keep two trees of one project side by side — which is also the case where writing to the wrong one is hardest to notice.

Suggested handling

Beyond fixing the comparison: when a session resumes with a primary working directory different from the one recorded in its transcript, say so in the UI rather than resuming silently. That turns this class of bug from silent-wrong-repo into a visible prompt.

Environment

• Claude Code in the Claude Desktop app (Code tab), macOS (Darwin 25.6.0), Apple Silicon
• App version: <!-- please fill in from the app's About dialog -->
• Model: Opus 5
• Both folders are independent clones, not git worktrees (git worktree list shows a single entry in each)

Related issues

These look adjacent but describe different layouts, and both were closed as duplicates without a linked canonical thread:

• #55034 — sessions grouped under the wrong project; sibling services under a shared parent, reporter suspects parent-folder matching rather than prefix matching
• #56688 — primary working directory locked to a folder other than the one selected; the two folders are unrelated rather than prefix-related
• #69105 — grouping generally disconnected from working directory