Add a `warp <path>` desktop launcher for directories and files

[psh4607]

Pre-submit Checks

• I searched Warp feature requests and did not find an issue for this focused desktop-launcher workflow.
• I searched the Warp documentation and did not find a supported warp <path> command.

Describe the solution you'd like?

Add a small, editor-style desktop launcher command for opening local paths in Warp:

warp .
warp AGENTS.md

Expected behavior:

1. warp <directory> launches or focuses the stable Warp desktop app and opens a terminal tab whose working directory is that directory.
2. warp <file> launches or focuses Warp and opens the file in Warp's built-in editor/Markdown viewer.
3. Relative paths are resolved from the caller's current working directory.
4. warp with no path launches or focuses the desktop app.
5. The Preview channel can use a channel-specific name such as warp-preview, consistent with oz-preview and warpctrl-preview.

This should be a thin desktop-launcher surface, not a replacement for either existing CLI:

• oz remains the agent CLI.
• warpctrl remains the richer API for controlling a running Warp instance.

The underlying app capabilities already exist:

• directories can be opened with warp://action/new_tab?path=... or the OS file-open event;
• files can be opened with warp://action/open_file_editor?path=... (implemented by Support warp://action/open_file_editor URIs #10233 for Feature request: support opening an external file at a specific line via URL Scheme and CLI #9561);
• warpctrl file open <path> can open a file when a controllable app instance is already running.

The requested command would make those capabilities easy to discover and use from shells and IDE integrated terminals, while also handling app startup and channel routing.

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

Developer tools commonly expose a memorable path launcher such as code .. Warp currently requires platform-specific commands or a user-maintained wrapper:

open -a Warp .
open "warp://action/open_file_editor?path=/absolute/path/to/AGENTS.md"

That is harder to remember, differs by operating system, and requires callers to choose different mechanisms for files and directories. The CLI portion of #9561 was deliberately left out when its URI support was implemented, and a later comment on that issue specifically requested warp . from an IDE integrated terminal. This issue tracks that narrower follow-up rather than reopening the file URI design.

Related but distinct:

• Feature request: support opening an external file at a specific line via URL Scheme and CLI #9561 / Support warp://action/open_file_editor URIs #10233: external file opening via URI, now complete
• Add a warpctrl local-control CLI for scripting Warp #11545: broad warpctrl scripting and live-instance control
• When we open Warp from other terminal, it opens two windows. #2933: duplicate-window bug in the current macOS open -a Warp . workaround

Additional context

Locally verified on Warp 0.2026.07.08.17.54.02 for macOS. A shell wrapper around the existing OS open events works for both examples, which demonstrates the user flow, but shipping the launcher with Warp would make it portable, documented, channel-aware, and supportable.

Operating system (OS)

Cross-platform

How important is this feature to you?

4

[oz-for-oss]

@psh4607

Here's what I found while triaging this issue:

This looks like a valid enhancement gap rather than a bug: Warp has URI/file-open and warpctrl file open plumbing, but I did not find a shipped warp <path> desktop launcher that handles app startup, directory opening, relative paths, and channel routing. Related work exists in #9561/#10233 and #11545, but this request is narrower and distinct.

Maintainer details

I concluded that enhancement request for a cross-platform warp <path> desktop launcher that starts or focuses Warp and opens directories or files through existing app routing..

Triage summary

This is a well-scoped enhancement request for a desktop-launcher command, not a bug report. The ask is to ship a channel-aware warp <path> / warp-preview <path> style entry point that starts or focuses Warp, resolves relative paths from the caller's working directory, opens directories as terminal tabs at that path, and opens files in Warp's editor or Markdown/notebook viewer.

Current-state evidence

• The shared Warp executable already accepts hidden URL startup args, and the app has URI/file-open handlers for adjacent behavior: warp://action/new_tab?path=..., warp://action/open_file_editor?path=..., and file:// routing for directories and openable files.
• Stable and Preview command names are currently oriented around oz / oz-preview for the agent CLI and warpctrl / warpctrl-preview for local control. I did not find a shipped warp* desktop-launcher command path that accepts arbitrary local filesystem paths.
• warpctrl file open <path> covers opening files against a controllable running instance, but it is intentionally a richer local-control surface and does not fully cover app startup, directory opening, relative-path resolution, or a simple code .-style launcher UX.

Duplicate check

I checked all open issues via the GitHub API. Related but distinct issues include #8741 for broader CLI hooks, #11545 for the warpctrl local-control CLI, #9083/#12343 for Tab Config CLI/URI automation, #2933 for a macOS open -a Warp . duplicate-window bug, and the completed #9561/#10233 URI-file-opening work. I did not find two or more existing open issues that match this narrower desktop-launcher request closely enough to mark it as a duplicate.

Suggested next step

This likely needs product/technical specification before implementation because it touches command naming, packaging/install paths, cross-platform startup forwarding, file-vs-directory routing, and channel-specific behavior.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[psh4607]

Thanks for triaging this. I'm happy to draft the product and technical specs, then follow through with the implementation once this is marked ready-to-spec. I've validated the workflow with a local wrapper and will wait for readiness before opening a PR.