[FEATURE] Open Claude Desktop in a specific folder via CLI flag or deep link (new Code session, not Cowork home)

+1 with an extension: alongside opening a new Code session in a folder, please also support resuming an existing Code session by UUID via deep link.

The chat side already supports claude://claude.ai/chat/{conversation-id} and claude://claude.ai/project/{project-id} — completing the pattern with claude://code/session/{uuid} (or claude://code/resume?uuid=...) would be the natural symmetry.

Why both matter together

• ?cwd= (this issue): "start fresh in this folder" — covers Finder/Raycast/Alfred entry points.
• /session/{uuid}: "jump back into the conversation I left off in" — covers the very common Stop-hook → OS notification → click-to-resume loop.

Concrete use case

A natural fit for hooks: configure a Stop hook that fires an OS-native notification (Windows toast, macOS notification) when a long-running session finishes. Today the notification can only nudge the user — clicking it can't actually take you back to the right session, because there's no URL that resolves to a specific Code session in the desktop UI.

With claude://code/session/{uuid} (or claude://code/resume?uuid=...), the notification's onclick becomes a one-liner: open the deep link, desktop app pops to front, sidebar selects the session, you're back in context. This is a standard OS pattern — it just needs the URL handler to exist.

The desktop sidebar redesign (April 2026) already exposes a stable session list, so this is mostly a routing problem at this point. Both ?cwd= (new session in folder) and /session/{uuid} (resume by UUID) together close the gap completely.

please do something so that i can claudecode . in the terminal and open this directory in the desktop client.

Yep, this is weird, since the deep link documentation seems to indicate you should be able to open in Claude Code: https://support.claude.com/en/articles/14729294-open-claude-desktop-with-a-link However it always seems to redirect to the Cowork home, I think this is actually a bug.

**Use case: a third-party tool that needs to focus an existing Code session in Claude Desktop**

I'm building Interlude — a macOS tool that plays your saved content (videos, articles, podcasts, music) while your AI agents work, turning agent wait-time into something useful. It runs alongside Claude Code and surfaces your running sessions, and we want a click on a session to bring Claude Desktop forward on that exact existing conversation. (This extends #54614 from "open a new session" to "focus an existing one," which is what the now-closed #50345 asked for.)

The ask — either option solves it:

1. A non-forking deep-link to an existing session — claude://claude.ai/code/<sessionId> that navigates Desktop to the existing Code session and foregrounds it. Today /code/… only accepts /code/new, and bridgeSessionIds is no longer written to the per-session JSON, so there's no addressable route to an existing session.
2. — or — origin-allow the existing internal setFocusedSession / focusAppAndNavigate for a trusted local caller (a documented localhost endpoint or URL handler taking a cliSessionId). The primitive already exists; it's gated to Desktop's own renderer (senderFrame.parent === null && origin ∈ claude.ai).

We already hold the cliSessionId (the hook payload's agent_id) per session and resolve its local_<id> — we're wired to consume a focus route the instant one exists.

Everything we tried first (macOS, live-probed 2026-06-18 — Desktop 1.13576.4 / Electron 42.4.0 / CLI 2.1.177):

| Approach | Result |
|---|---|
| claude://…/code/<bridgeSessionId> deep-link | Dead — route is /code/new-only; bridge ids absent from session files |
| claude://…/chat/<id> | Addresses claude.ai chats, not Code sessions (no-op) |
| claude://resume?session=<id> | Forks a new chat |
| Replay the CLI↔Desktop bridge frame | No local listener — inherited stdio socketpairs |
| macOS Accessibility sidebar navigation | Electron a11y tree won't build for third parties; also a privacy non-starter |
| Cooperative self-surface via a session notification (needsAttention→bringToFront) | Foreground primitive is origin-gated; not externally triggerable |
| OS window-raise | Works for terminal-hosted sessions (own window) but not Desktop (one window, many chats) |

Everything we'd do is local — zero network egress; we request no data, just a "focus session by id" affordance. Related: #50345 (asked for exactly this, closed), #65610 (deep-link background-navigate bug).

— Kevin Segel, Interlude · https://www.linkedin.com/in/kevinsegel/

FYI https://support.claude.com/en/articles/14729294-open-claude-desktop-with-a-link. So for me this works open claude://code/new?folder=/Users/weitzman/reps/tag1/metrialsvc

The repeated Trust prompt is a bit annoying but overall its nice.

Following up with what I found testing this end-to-end.

The original ask here — new Code session rooted at a folder — is resolved and now documented. claude://code/new?folder=<path> (optionally &q=<prompt>) opens a fresh Code session in that directory, exactly as requested in option B. It's now covered in the support article "Open Claude Desktop with a link". Confirmed working here; thanks @weitzman for surfacing it. q= prefills the composer too, which makes a one-click "open Claude Code with this prompt ready to run" button possible from a website or script.

The one gap that's still blocking a whole class of integrations: focusing an _existing_ Code session by id. code/new covers new sessions, but there's no working route to bring an _already-running_ Code session to the front. I traced every claude:// route in the Desktop binary (1.x) against ~/Library/Logs/Claude/main.log:

| Route | Behavior |
|---|---|
| claude://code/new?folder=&q= | ✅ works — new session in folder, prompt prefilled |
| claude://code/{session-id} | ⛔ the exact route for existing sessions — present but gated off. Desktop logs claudeURLHandler: code session deep link gated off (feature gate 2143883161). Its handler resolves the session id → navigates, so it looks ready; it's just disabled. |
| claude://claude.ai/chat/{id} | ❌ for existing sessions — this is the cloud conversation route; a local Code session's id 404s (chat_conversation_not_found) and falls back to recents |
| claude://claude.ai/local_sessions/{id} | ❌ navigates to Home, drops the id |
| claude://claude.ai/epitaxy/{id} | ❌ silent no-op |
| claude://resume?session={cli-uuid} | ⚠️ works but forks — imports a duplicate session rather than focusing the live one |

Request: enable claude://code/{session-id} (gate 2143883161). That single flag turns "jump to this running Code session" into reality — the natural counterpart to code/new, and the missing piece for any tool that surfaces running agents and wants to route the user back to the right one. Concretely: I'm building something that lists your running Claude Code agents and wants a click to route you back to the right session — the session id is already in hand and the click is wired to fire this link; it's dormant only because the gate is off.

Minor leftover from the original post: open -a "Claude" <folder> (option C, Finder-style folder association) still drops the path. Not a blocker given code/new?folder= exists, but it'd make right-click → "Open in Claude Code" work like every other dev app.