[FEATURE] "Open in Claude Code CLI" option in Desktop app

Resolved 💬 2 comments Opened Jun 14, 2026 by wcarpenter110981 Closed Jun 18, 2026

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

Feature Request: "Open in Claude Code CLI" option in Desktop app

Problem Statement

The Claude Code Desktop app currently offers three options when working with a project:

  • Open in File Explorer
  • Open in VS Code
  • New Window

There is no option to open the current project directly in a Claude Code CLI session. This creates a significant workflow gap for users who rely on Desktop for conversational and screenshot-heavy work but need CLI for tasks Desktop cannot perform.

Use Cases That Require CLI Today

  • Go builds and compilation — CLI inherits shell PATH and can run go build, go test etc. Desktop cannot
  • /goal autonomous multi-turn runs — set a completion condition and walk away; not fully supported in Desktop
  • /effort ultracode — dynamic workflow orchestration; CLI-first feature
  • Parallel Agent Teams — multiple Claude sessions messaging each other; CLI only
  • Headless/unattended execution — Desktop requires a foreground session
  • Terminal-dialog commands/permissions, /config, /agents, /doctor all return "isn't available in this environment" in Desktop

Current Workaround

Users must manually open a terminal, navigate to the project directory, and start a CLI session — losing the project context established in Desktop. For remote machines (e.g. a dedicated dev server over Tailscale/SSH), this requires additional tooling just to bridge the gap.

Proposed Solution

Add a fourth option to the Desktop project menu: see detail below

"Open in Claude Code CLI"

Behavior:

  • Opens a terminal window (Windows Terminal / iTerm2 / system default) pointed at the current project directory
  • Starts a claude CLI session with the same project context
  • Optionally inherits the current conversation as a starting prompt

Bonus: A companion option "Open CLI on Remote Machine" that SSHes into a configured remote host (e.g. a Tailscale-connected always-on dev machine) and starts the session there — enabling Desktop to orchestrate headless autonomous builds on dedicated hardware without leaving the app.

Why This Matters

Desktop and CLI are complementary, not competing. Desktop excels at conversational work, screenshot analysis, visual diff review, and plan approval. CLI excels at autonomous execution, parallel agents, Go/native toolchains, and unattended builds. Users shouldn't have to choose one or build custom bridging tools to use both together.

A single "Open in CLI" button would close most of the friction between these two surfaces.

Environment

  • Claude Code Desktop (Windows 11)
  • Claude Code CLI installed locally and on remote dev machine
  • Workflow: construction accounting firm automation, building Go CLIs, React/TypeScript apps on Supabase/Vercel stack

Proposed Solution

Here's a rewrite of just the Proposed Solution section — cleaner and more self-explanatory:

Proposed Solution
Add a fourth option to the existing Desktop project menu alongside "Open in File Explorer," "Open in VS Code," and "New Window":
"Open in Claude Code CLI"
When clicked, this option would:

Open the system's default terminal (Windows Terminal on Windows, iTerm2/Terminal on Mac)
Navigate automatically to the current project's directory
Start a claude CLI session — ready to use immediately, no manual navigation required

This is essentially the same behavior as "Open in VS Code" but targeting the terminal instead of an IDE. One click, project context intact, full CLI feature set available.
Optional but high-value addition: "Open CLI on Remote Machine"
For users with a dedicated always-on development machine (connected via Tailscale, SSH, or similar), a companion option that SSHes into that machine and starts the CLI session there would enable Desktop to serve as a lightweight front-end for autonomous builds running on more powerful hardware — without requiring custom tooling to bridge the gap.

Why not just use VS Code?
The VS Code extension is an excellent middle ground but still inherits some Desktop limitations around unattended execution and parallel agents. A native CLI option covers the remaining gap cleanly without requiring a third-party IDE to be installed or open.

Alternative Solutions

I've tried using multiple terminal windows, manually navigating to the project
directory and starting a CLI session separately from Desktop. This breaks
workflow continuity and requires constant context-switching between windows.

Currently I work around this by building a custom Go CLI (carpco-runner) that
uses PowerShell SendKeys and process management to bridge Desktop and a CLI
session — functional but fragile and something no user should have to build
themselves.

Other tools solve this by having the IDE/GUI spawn a terminal session directly
pointed at the active project (VS Code's integrated terminal being the obvious
example). Claude Code Desktop could do the same with one additional menu option.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

I use Claude Code Desktop for planning and conversational work — it handles
screenshots, visual context, and back-and-forth well. But when I need to build
Go CLIs (which require a real shell with PATH access), run /goal for autonomous
multi-turn builds, or use parallel Agent Teams, I have to manually open a
terminal, navigate to the project, and start a separate claude session from
scratch — losing the context established in Desktop entirely.

A concrete recent example: building a suite of Go CLI tools for a construction
accounting automation platform. Desktop planned each tool and generated the
commands, but couldn't execute them. I had to copy commands from Desktop, paste
them into a separate terminal, copy results back — essentially acting as a human
relay between two Claude sessions. An "Open in CLI" button would have eliminated
every manual step in that workflow.

Additional Context

Similar feature precedent: VS Code's "Open in Integrated Terminal" does exactly
this for a local shell. The ask here is the same pattern applied to Claude Code
CLI specifically.

Technical note: The implementation is likely straightforward — Desktop already
knows the project directory path (it uses it for File Explorer and VS Code
integration). Spawning a terminal process pointed at that path with claude as
the startup command is the same mechanism VS Code uses for its terminal
integration.

Remote variant note: For users with dedicated dev machines over Tailscale/SSH,
the remote CLI option would require a configured host in Desktop settings —
similar to how VS Code handles SSH remote development via the Remote-SSH
extension. This could ship as a follow-on to the simpler local CLI option.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗