claude-code - 💡(How to fix) Fix Remote Control sessions show in 'Other' instead of correct project folder in Desktop app

Bug Description

When a CLI session is connected to the Desktop app via Remote Control (/remote-control or claude://code/<bridgeSessionId>), it appears in the "Other" project folder in the sidebar. The same session opened via /desktop correctly appears under its project folder.

Environment

• OS: Windows 11 Pro 10.0.26200
• Claude Code CLI: v2.1.143
• Claude Desktop: Store package v1.7196.0.0 (MSIX)
• Working directory: Non-git project directory

Steps to Reproduce

1. Start a CLI session in a non-git project directory with remoteControlAtStartup: true
2. Connect via Remote Control (session appears in Desktop sidebar under "Other")
3. From the same CLI session, run /desktop (session appears under the correct project folder)

Root Cause (from Desktop main.log)

The two handoff paths run different initialization logic:

Remote Control (bridge session):

[CCD] LocalSessions.setFocusedSession: sessionId=session_01VrUWfg<redacted>
LocalSessions.checkGhAvailable: cwd=<project_dir>

Only checkGhAvailable runs. The session is focused under its bridge ID (session_*) but never gets a local_* identity or project binding.

/desktop (local session):

[CCD] LocalSessions.getDefaultPermissionMode: cwd=<project_dir>
LocalSessions.checkTrust: cwd=<project_dir>
LocalSessions.checkGhAvailable: cwd=<project_dir>

Full initialization → creates local_* session file with cwd/originCwd → project grouping logic fires.

Key evidence: The Desktop app DOES know the CWD for bridge sessions (logged in checkGhAvailable), but never uses it for project categorization.

Analysis

Expected Behavior

Remote Control sessions should be grouped into the same project folder as they would be via /desktop, since the CWD is already available.

Suggested Fix

When the Desktop app focuses a bridge session via setFocusedSession(session_*):

1. Read the CWD (already available — used in checkGhAvailable)
2. Apply the same project-grouping logic used for local_* sessions (git-root or CWD-path fallback)
3. Display the session under the resolved project folder, not "Other"

The data is already there — it's a missing code path, not missing metadata.

Additional Context

Also observed: claudeURLHandler: unrecognized code path { pathname: '/<bridgeSessionId>' } when launching via claude://code/<bridgeId>. The handler doesn't recognize the bridge session URI format, but the buddy bridge still picks it up and connects. Fixing the URL handler to explicitly route bridge session URIs would make the connection cleaner.