Repository navigation
Start npm-shim vendor CLIs directly on Windows - #1487
Conversation
Availability resolves a bare name through PATHEXT and finds npm's .cmd shim, but a shell-less spawn reaches only .exe, so OpenCode, Gemini and Copilot were offered and then failed to launch. The shim's own target is started so cmd.exe never parses vendor arguments. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every Windows launch is refused on platform, yet availability looked only at the binary, so the app offered a vendor that could only fail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 22 functions across 12 files. | Write docstrings for the functions missing them to satisfy the coverage threshold. |
-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title clearly and concisely describes the main change: direct Windows launches for npm-shim vendor CLIs. Linked Issues check Issue #1486requires Windows launch support for OpenCode, Gemini, and Copilot.WindowsLaunchCommand.Applyresolves commands withBinaryProbeand starts npm shims through their Node script or nativ…Out of Scope Changes check The changes stay within #1486. The resolver, launch call-site updates, version-probe update, Antigravity Windows gate, and supporting tests all address the documented Windows bare-spawn and advertisin…Full details: Linked Issues check
-
Explanation
Issue
#1486requires Windows launch support for OpenCode, Gemini, and Copilot.WindowsLaunchCommand.Applyresolves commands withBinaryProbeand starts npm shims through their Node script or native target. The call sites include ACP launches, version probing, Codex MCP inventory and app-server launches, Pi, and Muse. Unit tests cover shim resolution, native targets, unresolved commands, and argument ordering. Antigravity now returns unavailable on Windows, as required by#1486.
Full details: Out of Scope Changes check
-
Explanation
The changes stay within
#1486. The resolver, launch call-site updates, version-probe update, Antigravity Windows gate, and supporting tests all address the documented Windows bare-spawn and advertising defects. No unrelated feature change is shown.
-
- Fix all pre-merge checks with AI
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
PR Summary by QodoLaunch npm-shim vendor CLIs directly on Windows
AI Description
Diagram
High-Level Assessment
Files changed (12)
|
Code Review by Qodo
1. Windows version checks still fail
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| var (program, script) = Resolve(psi.FileName, binaries.Resolve, NpmCmdShim.TryRead); | ||
| psi.FileName = program; | ||
| if (script is not null) { | ||
| if (string.IsNullOrEmpty(psi.Arguments)) psi.ArgumentList.Insert(0, script); | ||
| else psi.Arguments = $"\"{script}\" {psi.Arguments}"; | ||
| } |
There was a problem hiding this comment.
1. Windows version checks still fail 📎 Requirement gap ☼ Reliability
VendorVersionResolver.Resolve starts the .cmd path returned by BinaryProbe without applying WindowsLaunchCommand, so Windows still attempts to launch the npm shim directly without its Node target. Any Muse, Pi, or Antigravity version probe that resolves to an npm .cmd shim therefore reports an unknown version and can incorrectly make the vendor unavailable.
Agent Prompt
## Issue description
WindowsLaunchCommand is applied to vendor launches, but VendorVersionResolver still starts the `.cmd` path returned by BinaryProbe directly. Version probes for npm-installed Muse, Pi, or Antigravity CLIs can therefore fail and report an unknown version on Windows.
## Fix Focus Areas
- src/Capacitor.Cli.Daemon/Services/WindowsLaunchCommand.cs[12-20]
- src/Capacitor.Cli.Core/VendorVersionResolver.cs[10-22]
## Recommended Fix
Apply the Windows launch transformation to the ProcessStartInfo used by VendorVersionResolver, passing the same BinaryProbe instance, so `.cmd` shims are replaced with their native executable or Node script target before Process.Start. Add a Windows-focused test that resolves a vendor version through an npm shim and verifies the transformed executable and arguments.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
2 participants
Closes #1486 — AI-3780
What & why
On Windows the app offered OpenCode, Gemini and Copilot, and every launch failed: availability finds npm's
.cmdshim through PATHEXT, but the daemon spawns the bare name without a shell, which reaches only.exe.WindowsLaunchCommandresolves the command with the sameBinaryProbeand starts an npm shim's own target (node.exe script, or its native.exe), so cmd.exe never parses vendor arguments. It is a no-op off Windows. Antigravity, refused on Windows on platform, is no longer advertised there (#1485 tracks real support).Where to look
ProcessStartInfobuilder, so builder tests are unchanged.Verification
Win32Exception (2)Win32Exception (2)Win32Exception (2)From the desktop app on this branch, OpenCode, Copilot, Kiro, Pi and Codex launch and answer. Daemon suite on Windows: 4,171 run, 15 failed — 14 symlink tests needing Developer Mode, 1 ConPTY job-object test on a path this change does not touch.
🤖 Generated with Claude Code
Summary by CodeRabbit