Sessions with a worktree CWD appear under `Other` instead of the parent project in Desktop sidebar

Summary

When I create or open a Claude Code session via Remote Control from a specific project, the session works correctly and has the right project context, but in the Desktop app sidebar it is sometimes grouped under Other instead of the expected project.

This seems to happen when the session's working directory is a Claude-managed git worktree path rather than the repository root.

What works

• The session itself has the correct repository context.
• Project memory is resolved correctly at the repository level.
• Remote Control sessions that were originally started from the Mac in the project directory often appear under the correct project.

What looks wrong

• A new session created from the Desktop UI (+) while viewing a specific project may appear under Other.
• A Remote Control session whose CWD is a Claude-managed worktree also appears under Other, even though it is logically part of the same project.

Reproduction

1. Open a project in Claude Code Desktop.
2. Use Remote Control with a session whose working directory is inside a Claude-managed git worktree, e.g. something like /path/to/repo/.claude/worktrees/....
3. Or create a new session via the + button while viewing that project.
4. Observe the left sidebar.

Expected behavior

The session should be grouped under the project I am currently in (or under the repository root project), even when the actual working directory is a Claude-managed git worktree for that repository.

Actual behavior

The session is shown under Other in the sidebar, despite:

• having the correct repo context,
• sharing the same project memory,
• and being effectively part of the same repository/project.

Additional observations

The behavior suggests different keys are used for different parts of the system:

• Session storage/grouping appears to be keyed by the exact CWD/worktree path.
• Project memory appears to be keyed by the repository root project.

So the session is functionally attached to the correct repo, but the sidebar grouping does not normalize the worktree path back to the parent project.

I confirmed this on a real session: the same session stored its transcript under a -Users-…-repo--claude-worktrees-<name> project directory, while its memory was read from the -Users-…-repo project directory — two separate keys for what is logically the same project.

Environment

• Claude Code Desktop on macOS
• Remote Control connected to a Mac
• Repository uses Claude-managed git worktrees

Notes

Local paths and IDs are redacted.