Warp host tool shows "not detected on $PATH" on Windows/Linux — catalogue entry is macOS-only but not platform-gated

[cbeaulieu-gt]

What users will see

In the project Hand-off menu ("open project in "), Warp is listed but always renders as unavailable with the tooltip "Warp - not detected on $PATH", even when the Warp terminal is installed. This happens on Windows and Linux; Warp can only ever be detected on macOS.

Environment (reporter)

• OS: Windows (MINGW64_NT-10.0-26200)
• Warp installed at: C:\Users\chris\AppData\Local\Programs\Warp\warp.exe (official Windows installer location; WarpPreview also present)
• where warp / which warp → not on PATH (the Warp Windows installer does not add a warp shim to $PATH)

Steps to reproduce

1. On Windows (or Linux), install Warp via the official installer (lands in %LOCALAPPDATA%\Programs\Warp\warp.exe, not added to $PATH).
2. Open the project Hand-off menu in OpenDesign.
3. Warp appears in the "unavailable" rail with "Warp - not detected on $PATH".

Expected: Warp is detected (or, if Warp open-in-app is not supported off-macOS, it is hidden on those platforms rather than shown as broken).
Actual: Warp is shown but is permanently undetectable on Windows/Linux.

Root cause

The host-tool catalogue entry for Warp declares only a macOS bundle fallback and no command, and it carries no platforms / excludedPlatforms guard — so it is shown on every platform but can only resolve on macOS.

apps/daemon/src/routes/host-tools.ts:70

{ id: 'warp', label: 'Warp', icon: 'sliders', macOpenBundle: 'Warp' },

resolveEntry() — apps/daemon/src/routes/host-tools.ts:160-191:

async function resolveEntry(entry: CatalogueEntry): Promise<{ /* … */ }> {
  if (entry.command) {                       // ← skipped: Warp has no `command`
    const resolved = await probeCommandOnPath(entry.command);
    if (resolved) { return { available: true, /* … */ }; }
  }
  if (entry.macOpenBundle && process.platform === 'darwin') {   // ← gated darwin-only
    const bundle = await probeMacBundle(entry.macOpenBundle);
    if (bundle) { return { available: true, /* … */ }; }
  }
  return { available: false };               // ← Windows/Linux always land here
}

So on Windows/Linux:

• The entry.command branch is skipped (Warp has no command).
• The macOpenBundle branch is gated process.platform === 'darwin'.
• → resolveEntry unconditionally returns { available: false }.

Detection never probes the actual Windows install path (%LOCALAPPDATA%\Programs\Warp\warp.exe), Program Files, the Windows registry App Paths, or Start Menu shortcuts.

The user-facing string: apps/web/src/i18n/locales/en.ts:596

'handoff.notDetectedTitle': '{target} - not detected on $PATH',

Contrast: the terminal entry (host-tools.ts:69) is correctly platform-gated with platforms: ['darwin'], so it is hidden off-macOS instead of shown-but-broken. Warp lacks the equivalent guard.

Suggested fixes (pick per product intent)

1. Add Windows/Linux detection for Warp — probe well-known install paths when the binary is not on $PATH:
   • Windows: %LOCALAPPDATA%\Programs\Warp\warp.exe (and WarpPreview), plus %PROGRAMFILES%\Warp\.
   • Linux: warp-terminal on $PATH / standard install dirs.
     This needs a new path-probe fallback in resolveEntry (the current logic only knows $PATH + macOS bundles).
2. Add command: 'warp' so a $PATH shim is honored on all platforms (helps users who do have the shim, but does NOT fix the installer-default case since Warp's Windows installer doesn't add a shim).
3. Minimal stop-gap: add platforms: ['darwin'] (or excludedPlatforms: ['win32', 'linux']) to the Warp entry so it is hidden where it cannot be detected, matching the terminal entry — until proper detection lands.

Options 1 + 3 could ship together (hide now, enable on real detection later).

Notes

• Reported via OpenDesign on Windows; same defect applies to Linux by code inspection.
• No existing issue found for Warp detection; closest prior art with the same "installed but not detected" shape: Kimi Code CLI is not detected and ACP runs fail after official update #4190 (Kimi Code CLI PATH resolution) and [Gemini CLI] DMG app picks up old gemini binary on PATH → Unknown arguments: output-format, outputFormat #978 (Gemini CLI wrong binary on PATH) — both agent-runtime detection, not host-tool detection.

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

[cbeaulieu-gt]

/claim

[lefarcen]

Hi @cbeaulieu-gt! Thanks for the very careful write-up here — the comparison with the darwin-gated terminal entry makes the failure mode easy to follow.

You're right: as host-tools.ts stands today, the Warp entry is visible on every platform but can only ever resolve on macOS, so Windows/Linux will always fall through to unavailable. The shortest safe fix is to gate Warp to darwin until we have real non-macOS detection; the fuller fix would be to add Windows/Linux probes before keeping it visible there.

I've labeled this as a bug and marked it as a good community issue since the scope looks nicely contained around the host-tool catalogue/probing path. If you want to take a crack at it, happy to review a PR.

[lefarcen]

Hey @cbeaulieu-gt — appreciate you picking this up. Given the scope around the host-tool catalogue/probing path, what feels realistic on your side: a few hours, 1–3 days, around a week, or longer?

[cbeaulieu-gt]

Should be ready by tomorrow at latest

[lefarcen]

Heads-up: PR #4542 is now open for this.

The current fix path is to add a Windows install-path probe for Warp plus the direct-launch handling needed to avoid the win32 shell:true failure mode, so the issue stays open until that lands and we can verify it end to end.

[cbeaulieu-gt]

Update — gated by Warp upstream.

Windows detection is fixed in #4542, but the full "Open in Warp at the project directory" can't ship yet: Warp has no reliable directory-targeted launch. Verified on Windows — cold start ignores the working dir (opens at home); only a warm relaunch (Warp already running) honors it. That inconsistency is invisible to users and a bug magnet.

This is gated by upstream warpdotdev/warp#6357 (a possible upcoming Warp feature). Per review on #4542, that PR is parked as a draft, and we'll hide the Warp launcher on Windows/Linux until upstream lands — tracked in #4544.

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

[lefarcen]

Hey @cbeaulieu-gt — thanks for digging all the way through the cold-start vs warm-relaunch behavior and spelling out the upstream gate so clearly.

That makes sense to us: if Warp can't reliably open at the project directory on a cold start, hiding the launcher on Windows/Linux until warpdotdev/Warp#6357 (or an equivalent upstream capability) lands is the safer path. Parking #4542 as draft and tracking the stop-gap in #4544 feels like the right move.