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/<user>/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/<user>/workspaces/<project>). Let it run.

1. In the sidebar, click the "+" on that project's row.
2. Observe: the generic "+ New" view opens, folder not pre-filled.
3. Control: repeat 1–3 with a Local project on a Windows path

(e.g. C:\Users\<user>\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\<user>\Desktop\Workspaces\test project
14:18:33  LocalSessions.saveTrust: cwd=C:\Users\<user>\Desktop\Workspaces\test project
14:18:47  Starting local session local_b679b4e6… in C:\Users\<user>\Desktop\Workspaces\test project
14:19:20  Starting local session local_ce23e338… in C:\Users\<user>\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/<user>/.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/<user>/workspaces/<project>
11:34:06  Starting local session local_f0b77187… in /home/<user>/workspaces/<project>

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:<distro>:<path> 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.