[FEATURE] --desktop CLI flag to launch/continue sessions directly in the Desktop app, with option to target current or new window

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The /desktop slash command is currently the only way to move a Claude Code CLI session into the Desktop app. It requires a manual round-trip: start the CLI with claude (or claude -c / -r / --resume), wait for the TUI to load, type /desktop, wait for the handoff, CLI exits, UI opens the session.

For developers who live in the terminal but prefer the Desktop app's visual diff view, sidebar session management, and integrated preview pane, this interactive two-step adds friction to every session start and cannot be cleanly scripted. There's no CLI flag equivalent for this routing — the official CLI flag equivalents table lists "click a session in the sidebar" as the Desktop equivalent of --resume / --continue, which doesn't cover the "start from the shell, land in UI" case.

There's also no way to control which Desktop window receives the session. Today, /desktop always hands off to the single running app instance. Users who want to work across multiple monitors with separate UI windows (see related #30154) have to rely on open -n -a "Claude" hacks that double memory usage and don't integrate with normal session routing.

Proposed Solution

Primary: Add a --desktop flag that composes with existing session flags so a single CLI invocation launches the session directly in the Desktop UI, skipping the interactive TUI entirely:

claude --desktop                            # new session, opens in UI
claude -c --desktop                         # continue most recent, open in UI
claude -r "refactor-auth" --desktop         # resume by name, open in UI
claude --resume  --desktop      # resume by ID, open in UI
claude -w --desktop                         # new worktree session, open in UI
claude --desktop "fix the login bug"        # new session with initial prompt

Semantically equivalent to running the corresponding CLI session and immediately typing /desktop, but scriptable and non-interactive. Fits naturally alongside the existing --teleport flag as part of the session-routing surface.

Secondary: window target option. Pair the flag with a way to control which Desktop window receives the session. Either as a value on --desktop or a separate --desktop-window flag:

claude --desktop                            # default: add to current running UI window's sidebar
claude --desktop=current                    # same, explicit
claude --desktop=new-window                 # spawn a fresh UI window for this session

The new-window mode would officially support the multi-window use case requested in #30154 without users resorting to open -n -a "Claude" or similar workarounds. It also enables power-user workflows where dozens of parallel Claudes run with a dedicated window per project or per monitor.

Use Cases

• Terminal-first developers with visual review preferences: jump a CLI-initiated session into the UI for diff review / preview without a two-step handoff.
• Multi-monitor workflows: dedicate one Desktop window per major project or monitor (--desktop=new-window) rather than cramming all sessions into a single window's sidebar.
• Scripting and shell aliases: wrappers that launch claude -c --desktop on demand become trivial one-liners. Today these require expect or stdin-injection tricks that are fragile across Claude Code versions.
• WSL / cross-platform launch: start a session from a WSL/Linux shell script and have it open in the Windows-side Desktop UI without interactive input.
• CI/debug handoff: when a CI run fails, a helper command can spawn a Claude session scoped to the failing commit and drop it straight into the UI for human review.
• IDE / editor integrations: third-party editor plugins can offer "open this repo in Claude Desktop" as a one-command action.

Alternative Solutions

• Current two-step workflow (claude -c + /desktop): works but requires interactive input; not cleanly scriptable.
• expect / PowerShell stdin injection: technically possible but fragile — breaks whenever the TUI startup sequence changes.
• Launch app manually + click session in sidebar: works for resuming existing UI sessions but doesn't cover "start from a CLI-specified session ID" or "continue a CLI-only session".
• open -n -a "Claude" for multi-window: doubles memory usage; second instance doesn't share session state cleanly; macOS-only.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_