## Environment - Claude Desktop 1.46388.3 (Windows 11, Microsoft Store / MSIX package), bundled engine 2.1.260 - Also verified: 1.37937.3 and 1.40609.0 did **not** have this behaviour (same links worked on 2026-08-27 and 2026-08-28) ## What happens Opening a deep link `claude://code/new?folder= &q= ` shows the "Trust this workspace?" dialog for the right folder. After clicking "Trust workspace", the composer chip shows the folder and the prompt is prefilled. Pressing Enter

Desktop 1.46388: claude://code/new?folder= starts a scratch workspace when the folder equals the currently selected folder

Status Open

Reported on v2.1.260

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 9 comments · opened Sep 4, 2026

Environment

Claude Desktop 1.46388.3 (Windows 11, Microsoft Store / MSIX package), bundled engine 2.1.260
Also verified: 1.37937.3 and 1.40609.0 did not have this behaviour (same links worked on 2026-08-27 and 2026-08-28)

What happens

Opening a deep link claude://code/new?folder=<absolute path>&q=<text> shows the "Trust this workspace?" dialog for the right folder. After clicking "Trust workspace", the composer chip shows the folder and the prompt is prefilled. Pressing Enter starts the session in a freshly minted scratch workspace (the "No folder" list) instead of the folder. The prompt text arrives intact.

%LOCALAPPDATA%\Claude\Logs\main.log for one click:

15:46:55 [info] LocalSessions.checkTrust: cwd=C:\Users\<me>\cases\<folder>
15:46:57 [info] LocalSessions.saveTrust: cwd=C:\Users\<me>\cases\<folder>
15:46:57 [info] Saved workspace trust for C:\Users\<me>\cases\<folder>
15:47:17 [info] LocalSessions.createScratchWorkspace
15:47:17 [info] [CCD] minted scratch workspace C:\Users\<me>\AppData\Roaming\Claude\scratch-workspaces\...\scratch-2026-09-04-43ac21
15:47:18 [info] Starting local session local_... in C:\Users\<me>\AppData\Roaming\Claude\scratch-workspaces\...\scratch-2026-09-04-43ac21

Trigger

The folder in the link is the same string as the folder already selected in the composer (the folder of the last local session, or one picked manually). When the selected folder is different, the very same link works — the log then shows saveTrust → checkGhAvailable: cwd=<folder> → Starting local session ... in <folder>.

A different spelling of the same path (C:/Users/... instead of C:\Users\..., or a lowercase drive letter) also makes the link work, which points to a plain string comparison in the renderer. Those spellings then show up as separate groups in the sidebar, so this is not a usable workaround.

Steps to reproduce

Start any session in folder X from the sidebar (or pick X in the composer).
Open claude://code/new?folder=<X>&q=hello (e.g. Start-Process in PowerShell).
Click "Trust workspace" on the dialog.
Press Enter.

Expected: session starts in X. Actual: session starts in %APPDATA%\Claude\scratch-workspaces\..., listed under "No folder".

Reproduced 4 times in a row on the same machine; opening a different folder via the same link right before makes the next attempt succeed.

Why it matters

We launch Claude Desktop from an internal app with the folder of the current matter and a prefilled prompt. Users typically reopen the same folder they were just working in, which is exactly the failing case.

View original on GitHub ↗

3 Comments

CrazyCoder · 1 month ago

Still reproduces on Claude Desktop 1.52386.3.0 (Windows 10, MSIX), bundled engine 2.1.266, with a plain claude://code/new?folder=<path> link and no q=.

Same trigger: the folder in the link equals the folder already selected in the composer. After "Trust workspace" the folder chip shows the folder, but the branch chip next to it shows "—" instead of the branch, and Enter starts the session in a scratch workspace. Both a cold start (link launches the app) and a warm app behave the same.

main.log for one warm click:

15:07:00 [info] Starting app {
15:07:01 [info] second-instance: suppressing duplicate argv
15:07:02 [info] LocalSessions.saveTrust: cwd=<folder>
15:07:02 [info] Saved workspace trust for <folder>

and nothing follows until Enter. When the same folder is re-selected from the folder chip drop-down, the branch appears and the session starts in the folder, so that is the workaround we tell users.

From the web bundle: the external-folder confirm ends in applyLocalFolderPick(folder), which sets selectedFolder and resets trustedSelectedFolder to null. The composer's trust stage (the one that calls checkTrust again and then setTrustedSelectedFolder, which fills the branch and the session cwd) is keyed on selectedFolder changing. When the link's folder equals the current selectedFolder, nothing changes, the stage never runs, and the folder stays untrusted in the composer, which the "—" branch chip shows. Re-picking from the drop-down goes through the normal pick path and runs the stage. Keying that stage on folderPickEpoch as well would cover the deep link case.

PedroGiudice · 1 month ago

Thanks, this matches what we measured. Confirming independently on Windows 11, Desktop 1.46388.3 (MSIX, engine 2.1.260): a link whose folder equals the currently selected one goes to scratch, a different folder works, a different spelling of the same path (C:/Users/... vs C:\Users\...) also works but creates a separate group in the sidebar, and a link with only q= keeps the selected folder with no trust dialog.

Your trace of applyLocalFolderPick resetting trustedSelectedFolder while the trust stage is keyed on selectedFolder changing explains every row of our test matrix. On our side (a client app that opens cases via claude://code/new) the workaround is to omit folder when it equals the cwd of the last local session, read from %APPDATA%\Claude\claude-code-sessions\<acct>\<org>\local_*.json (originCwd/cwd + createdAt, scratch and SSH sessions ignored). The "—" branch chip is a useful tell we had not spotted.

anton-prod · 22 days ago

Still an issue in the latest app today.

Workaround is to add a slash at the end of the folder every other time

Showing cached comments. Read the full discussion on GitHub ↗