Hide the Warp "Open in…" launcher on Windows/Linux until Warp supports directory-targeted launch

[cbeaulieu-gt]

Follow-up to #4539 / #4542, per review by @nettee on #4542.

Background

#4542 makes the Warp host tool detectable and launchable on Windows (it was permanently "not detected on $PATH"). But it surfaced a deeper limitation: Warp has no reliable directory-targeted launch.

Empirically verified on Windows:

• Cold start (Warp not running): the spawn cwd is ignored — Warp opens at its default/home directory.
• Warm (Warp already running): a relaunch honors the cwd — the new tab opens at the project directory.

This cold/warm split is invisible to the user → a bug magnet: a user who keeps Warp closed clicks "Open in Warp", lands at home instead of their project, and reports "Open in Warp ignores my project" without knowing the caveat. The reviewer's "all or nothing" reading is fair.

Decision

Until Warp supports a directory-targeted launch upstream — warpdotdev/warp#6357, which appears to be a possible upcoming feature — hide the Warp launcher on platforms where it can't reliably target the directory (Windows, and Linux by the same gap) rather than ship inconsistent behavior. macOS (open -a Warp <dir>) is unaffected.

Scope

• In apps/daemon/src/routes/host-tools.ts, gate the Warp catalogue entry so it is not offered on win32/linux (e.g. platforms: ['darwin'], mirroring the terminal entry), OR keep detection but mark it unavailable, until dir-targeting lands.
• Revisit and re-enable when Allow launching Warp in a specified working directory (like "Open in Terminal") warpdotdev/warp#6357 ships.

Links

• Parks fix(daemon): detect and launch Warp on Windows for the open-in host tool (#4539) #4542 (now draft)
• Relates Warp host tool shows "not detected on $PATH" on Windows/Linux — catalogue entry is macOS-only but not platform-gated #4539 (Windows detection)
• Upstream gate: Allow launching Warp in a specified working directory (like "Open in Terminal") warpdotdev/warp#6357

🤖 Generated by Claude Code on behalf of @cbeaulieu-gt

[cbeaulieu-gt]

/claim

[lefarcen]

Hi @cbeaulieu-gt! 👋

The scope here makes sense: once #4542 proved Warp can be detected on Windows, the cold-start vs warm-relaunch split became the real blocker, and hiding the launcher on win32/linux until directory-targeted launch exists upstream is the safer behavior.

I’ve labeled this as a bug. Since the issue is already claimed/assigned to you and the implementation path is nicely scoped around apps/daemon/src/routes/host-tools.ts, feel free to keep going here — happy to review the follow-up PR once it’s up.

[lefarcen]

Hey @cbeaulieu-gt — really appreciate you picking this up.

Given the scope around the Warp platform gate, what feels realistic on your side: a few hours, 1–3 days, around a week, or longer?

[cbeaulieu-gt]

Less than a day

[lefarcen]

Heads-up: PR #4546 is up to implement the darwin-only Warp gate. It centralizes the platform restriction in applicableForPlatform, so the editor catalogue, the launch endpoint, and the win32/linux "Open with editor" menu all stay in sync while we wait on upstream directory-targeting support. Keeping #4544 open until that PR lands.

[lefarcen]

Heads-up: PR #4546 is up to implement the darwin-only Warp gate. It centralizes the platform restriction in applicableForPlatform, so the editor catalogue, the launch endpoint, and the win32/linux "Open with editor" menu all stay in sync while we wait on upstream directory-targeting support. Keeping #4544 open until that PR lands.