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

[gsamat]

Summary

No supported way to launch Claude Desktop directly into a new Code session rooted at a specific folder. Launching the app via dock icon, open -a "Claude", or open -na "Claude" --args ... always lands on the Cowork home / project picker, regardless of any path argument or claude:// URL.

Use case

I keep dozens of project folders. Today the only fast path to a Code session in /path/to/project is the terminal:

cd /path/to/project && claude

That works, but it's terminal-only. Inside Claude Desktop the workflow is:

1. Click the dock icon → Cowork home
2. Click "New session" → folder picker
3. Navigate to the folder → confirm
4. Wait for the session to spawn

Every time. No way to script it, no Finder right-click, no Raycast/Alfred integration, no .command shortcut.

What I tried

• open -na "Claude Code" --args --add-dir /path — opens Cowork home, args dropped (Electron single-instance lock, second-instance flags stripped).
• open -nb com.anthropic.claude-code --args /path — same.
• cd /path && open -na "Claude" — cwd not inherited by the Electron renderer; lands on home screen.
• claude:// scheme is registered (setAsDefaultProtocolClient("claude")), but no documented claude://session/new?cwd=... route. Disassembled app.asar — only cowork-artifact: / cowork-file: / claude-simulator: / operon-artifact: schemes are wired, none route to "new Code session in folder".
• claude-cli://open?q=... (existing scheme on the URL Handler app) launches the terminal CLI, not the desktop Cowork host.
• App ignores argv other than --startup (grep argv.includes in app.asar yields only "--startup").

Ask

Either of these closes the gap:

A. CLI flag

open -na "Claude" --args --cwd /path/to/project
# or
Claude.app/Contents/MacOS/Claude --cwd /path/to/project

Spawns a new Code session rooted at the given path, bypassing the Cowork picker. Equivalent to what the terminal CLI does today with cd && claude.

B. Deep link

claude://session/new?cwd=/path/to/project

Route the existing registered claude:// handler to the Code session router with a cwd query param. Symmetric with the deep-link request in #50345 (resume by UUID) — that one targets existing sessions, this one targets new sessions in a folder.

C. open <folder> association

Treat folder paths passed via open / Finder drag-onto-dock as "new Code session here":

open -a "Claude" /path/to/project

This is the standard macOS pattern (VS Code, Sublime, Xcode all do this). Today the path is silently dropped.

Why this matters

• Finder Quick Action — right-click folder → "Open in Claude Code" becomes possible.
• Raycast / Alfred / Shortcuts — power-user launchers can target Code sessions instead of being stuck at the picker.
• IDE-style workflow — match what every other dev desktop app on macOS does (code ., subl ., idea .).
• Scriptable from any tool — build hooks, post-commit triggers, CI dashboards can deep-link to a fresh Code session in the right folder.

The terminal CLI already does this trivially. Bringing the desktop app to parity unblocks a lot of automation.

Related

• Feature: open Claude Desktop to a specific session UUID via CLI flag or deep link #50345 — open Desktop to specific session UUID (closed as dup, but the underlying capability — deep-link routing in Cowork — is the same)
• Add /resume (session resume) to desktop app #50067 — /resume in desktop app
• [FEATURE] Allow -p sessions to appear in Claude Desktop sidebar (triggered remotely or via script) #43943 — claude-desktop://resume?session=<id> for -p sessions

This request is the new-session, by-folder counterpart to those (which are all resume, by UUID).

Platform

macOS 15.x (Darwin 24.6.0). Claude Desktop 1.5354.0, claude-code 2.1.121.

[hojeongna]

+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.

[banochkin]

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

[ThomasBurgess2000]

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.

[KevinSegel]

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/