Desktop + WSL: "+" on a project row opens the generic New view instead of starting a session in that project (Local works)

## Environment

- **Desktop app**: Windows 1.46388.4 (MSIX / Store install, `Claude_pzs8sxrjxfjjc`)
- **Session environment**: WSL 2 → Ubuntu-24.04 (kernel `6.6.87.2-microsoft-standard-WSL2`)
- **In-WSL agent binary**: `~/.claude/remote/ccd-cli/2.1.260`
- **Project**: a folder under `/home//workspaces/` on the Linux filesystem (not `/mnt/c`)

## Summary

In the Code tab sidebar, each project row carries a "+" affordance. For a project in a
**WSL** environment, clicking it does not start a session in that project. It navigates
to the generic "+ New" view with no folder pre-filled, so the environment and folder
have to be picked again by hand.

For a project in a **Local** (Windows) environment, on the same machine and account, the
same "+" works: it starts a session in that project directly, including a second
concurrent session in a project that already has one running.

I hit this trying to open a second session in a WSL project while the first was busy.

## Repro

1. Desktop app → Code tab → open a session in a WSL project (environment: WSL Ubuntu,
folder `/home//workspaces/`). Let it run.
2. In the sidebar, click the "+" on that project's row.
3. Observe: the generic "+ New" view opens, folder not pre-filled.
4. Control: repeat 1–3 with a Local project on a Windows path
(e.g. `C:\Users\\Desktop\Workspaces\test project`). The "+" starts a session in
that project as expected.

## Expected

The "+" on a project row starts a session in that project, on the same environment,
alongside any session already running there. This is what the Local path already does.

## Evidence

From `%LOCALAPPDATA%\Claude\logs\main.log`, same machine, account and day.

**Local (Windows) project — folder carried, second session starts clean.** Trust is
saved once, and the second session needs no further trust check:

```
14:18:31 LocalSessions.checkTrust: cwd=C:\Users\\Desktop\Workspaces\test project
14:18:33 LocalSessions.saveTrust: cwd=C:\Users\\Desktop\Workspaces\test project
14:18:47 Starting local session local_b679b4e6… in C:\Users\\Desktop\Workspaces\test project
14:19:20 Starting local session local_ce23e338… in C:\Users\\Desktop\Workspaces\test project
```

**WSL project — every new-session trust check resolves to `~`,** five times across the
day, never once to a project path:

```
13:47:30 checkRemoteTargetTrust: target=wsl:Ubuntu-24.04, cwd=~
13:52:42 checkRemoteTargetTrust: target=wsl:Ubuntu-24.04, cwd=~
14:00:38 checkRemoteTargetTrust: target=wsl:Ubuntu-24.04, cwd=~
14:13:33 checkRemoteTargetTrust: target=wsl:Ubuntu-24.04, cwd=~
14:19:00 checkRemoteTargetTrust: target=wsl:Ubuntu-24.04, cwd=~
```

and the session that follows lands in the home directory:

```
13:48:12 LocalSessions.saveTrust: cwd=wsl:ubuntu-24.04:~
13:48:12 Starting local session local_b11b238d… in ~
13:48:12 [SSH] Using remote spawn function … on wsl:Ubuntu-24.04 (cli: /home//.claude/remote/ccd-cli/2.1.260)
```

A WSL session does start in the right place when the folder is selected by hand, so the
remote spawn path itself is healthy. The folder simply never arrives from the "+":

```
11:33:08 checkRemoteTargetTrust: target=wsl:Ubuntu-24.04, cwd=/home//workspaces/
11:34:06 Starting local session local_f0b77187… in /home//workspaces/
```

Across the whole log a folder is never picked and then dropped. It is either present
from the first trust check, or the session lands in `~`.

The two branches are distinct: Local uses `checkTrust` with a plain path, WSL uses
`checkRemoteTargetTrust` with a `target=` and a `wsl::` trust key. The
defect is in the remote-target branch, which WSL shares with SSH remotes.

## Impact

Every additional session in a WSL project is a four-step manual detour (environment
picker → distro → folder picker → trust), repeated each time. Parallel sessions in one
project are the normal way to work on the Local path and awkward on WSL, for no reason
the UI communicates. The "+" appears project-scoped and silently is not.

## No workaround available

- **No setting.** The app's config (`…\LocalCache\Roaming\Claude\config.json` under the
MSIX redirect) has no key relating to directories, workspaces or projects.
- **No deep link.** The registered `claude://` handler exposes `code/new`,
`code/continue`, `code/needs-input`, `claude.ai/new`, `cowork/shared-artifact` and
`resume`. No route accepts a path parameter, so this cannot be scripted around.
#77750 reports the same gap from the onboarding side.
- `~/.claude/settings.json` configures the CLI after start, not the folder selection.

## Related

- #77750 — feature request for pre-configuring WSL environments and deep-linking a
Desktop session to a distro + folder. Same missing capability, different entry point.
- #78293, #92051 — other Desktop + WSL defects in the remote-target path.

Start with main.log and trace the Code tab project-row “+” action into the remote-target branch, comparing checkRemoteTargetTrust with the Local checkTrust path. Reproduce with a WSL Ubuntu project and verify that the selected project path reaches the trust check and that the resulting session starts there rather than in ~.

Vom Indexierungsmodell aus dem Issue-Text verfasst.