Add option to open directories in $EDITOR

[PaulRBerg]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

Add an option to open directories in $EDITOR when clicking directory paths printed in Warp's output.

Currently, clicking a directory path opens it in Finder. I'd like to keep Finder as the default system-wide behavior, but have Warp-specific behavior that opens directories in my configured editor (e.g., VS Code, Neovim) when I click them from terminal output.

This could be implemented as:

• A Warp setting to configure directory click behavior (Finder vs $EDITOR)
• A modifier key (e.g., Cmd+click opens in $EDITOR, regular click opens in Finder)
• A context menu option when right-clicking directories

Is your feature request related to a problem? Please describe.

When working in the terminal, I often encounter directory paths in command output (build logs, git status, file listings, etc.). When I want to explore or edit files in that directory, I currently have to:

1. Copy the path
2. Switch to my editor
3. Use "Open Folder" and paste the path

Being able to click directly to open in $EDITOR would streamline this workflow significantly.

Additional context

This would be especially useful for developers who:

• Work primarily in terminal-based editors (Neovim, Helix)
• Use VS Code or other editors with good directory/project support
• Frequently navigate between terminal output and code exploration

Operating system (OS)

macOS

How important is this feature to you?

3

[PaulRBerg]

Claude Code often prints output like this:

I'd like to be able to click on portal/ui/breadcrumb/ and have it be opened in Cursor (my $EDITOR) instead of Finder.

[brylee10]

I was just thinking about this as well. Currently "open in editor" only supports files.

[ATERCATES]

Hi! I built something close to what's described here on my fork while scratching the same itch (specifically, opening Claude/OpenCode CLI sessions' cwd in an IDE without losing flow). Sharing in case it helps with scoping.

What I implemented

A configurable "Open in IDE" chip in the prompt — added through the Edit Prompt modal like any other context chip. One variant per editor (VS Code, Cursor, Windsurf, Antigravity, Zed). It launches the editor on the current terminal cwd.

Differences vs the original ask in this issue

• Trigger is a chip in the prompt area, not a click handler on directory paths inside terminal output.
• The chip is opt-in: users drag it into the prompt (or into the CLI agent toolbelt) from the Edit Prompt modal — no defaults changed.
• Scope is the session cwd (local or warpified SSH), not arbitrary directories printed in output.
• Editors are an enum (WorkingDirEditor) backed by per-editor display_name / command / icon / ssh_remote_args via a single EditorMeta table. Adding a new editor = one entry.
• SSH: same chip works from inside an SSH session — the handler builds --remote ssh-remote+host … for VS Code-family editors and ssh://host/path for Zed.
• CLI agent sessions: the chip is also clickable from the CLI agent toolbelt while Claude/OpenCode/Codex run, since it spawns an external process (no shell input).

Note this is a complement to the original click-on-output proposal in this issue, not a replacement — the two could coexist: chip for the "I want to open here" intent, click-on-output for the "open this specific path" intent.

Code lives on my fork (ATERCATES/warp), squashed into PRs #3 and #4. Happy to clean up and propose upstream if useful — could go either as a spec PR proposing the chip approach, or as a code PR if the maintainers prefer the directory-click approach this issue describes.

@oss-maintainers — would you mind taking another look at this issue and applying `ready-to-spec` or `ready-to-implement` so the right path is clear? Happy to do whichever fits Warp's roadmap.

[0xBB2B]

Heads up — I'm prototyping a third UX vector for this on a fork, complementary to @PaulRBerg's click-on-output proposal and @ATERCATES's prompt-area chip:

Right-click a session tab or workspace picker entry → "Open with $EDITOR"

Rationale: the tab / workspace row is the most natural "this represents the current project" handle in Warp's UI. It works regardless of whether a path happens to be printed in terminal output, and it doesn't add anything to the prompt area.

Planned scope:

• Menu label is dynamic, driven by the existing ExternalEditor setting (e.g. "Open with VS Code", "Open with Cursor"). No hardcoding.
• Acts on the tab/session cwd (or workspace root for the picker).
• Gated behind a feature flag.

Plan to ship as a spec PR first (PRODUCT.md + TECH.md), then a flag-gated implementation PR, both linked to this issue.

Not trying to step on @ATERCATES's chip work — happy to defer or align if maintainers prefer one entry point over the other. Will hold off on the implementation PR until there's signal on direction.