Skip to content

fix: detect Windows npm CLI shims - #118

Open
adamkane wants to merge 1 commit into
vercel:mainfrom
adamkane:codex/fix-windows-cli-detection
Open

fix: detect Windows npm CLI shims#118
adamkane wants to merge 1 commit into
vercel:mainfrom
adamkane:codex/fix-windows-cli-detection

Conversation

@adamkane

Copy link
Copy Markdown

Summary

  • skip npm's extensionless POSIX shim when resolving CLIs on Windows
  • invoke .cmd and .bat launchers through a quoted cmd.exe command string
  • keep direct execution for native binaries and add Windows regression coverage

This prevents the session-start profiler from repeatedly reporting an installed Vercel CLI as missing. It also avoids Node's deprecated shell: true plus argument-array form.

Fixes #89
Fixes #95
Fixes #105

Verification

  • bun test hooks/session-start-profiler-platform.test.ts (4 passed)
  • bun run typecheck
  • bun run build:hooks
  • live Windows hook smoke test with npm-installed Vercel CLI 56.2.0 (no missing/outdated warning)

Existing upstream baseline failures

The broader Windows suite was also attempted. Untouched upstream/main currently fails build:from-skills:check and validate for stale template includes/command catalog rules; the full suite reports the same unrelated template and Windows path failures. This PR changes only the profiler source, generated hook, and its platform regression test.

@adamkane

Copy link
Copy Markdown
Author

@Melkeydev Could you please review this Windows CLI detection fix when you have a chance? The focused platform tests, hook build, and typecheck pass; the unrelated upstream baseline failures are documented in the PR description.

@agantelin

agantelin commented Jul 28, 2026

Copy link
Copy Markdown

Confirming this is still live on the current build — plugin 0.45.1 (the version currently vendored into anthropics/claude-plugins-official), so the linked reports are not stale.

Environment

  • Windows 11 Pro 10.0.26200, Node v24.18.0
  • Vercel CLI 58.0.0, global npm install. %APPDATA%\npm\ contains all three launchers: vercel (824 B POSIX shim), vercel.cmd (331 B), vercel.ps1 (833 B)

Repro, running 0.45.1's own resolution logic verbatim

resolveBinaryFromPath("vercel") -> C:\Users\<user>\AppData\Roaming\npm\vercel
execFileSync(bin, ["--version"], { stdio: ["ignore","pipe","ignore"] }) -> throws
  code:    ENOENT
  syscall: spawnSync C:\Users\<user>\AppData\Roaming\npm\vercel

getBinaryPathCandidates still builds ["", ...WINDOWS_EXECUTABLE_EXTENSIONS] (hooks/src/session-start-profiler.mts:339), so the extensionless POSIX shim is returned ahead of vercel.cmd. The throw is swallowed by the catch and checkVercelCli() returns { installed: false }.

Ruling out the obvious alternative: this is not the 3 s timeout. vercel --version measures 109–162 ms here against EXEC_SYNC_TIMEOUT_MS = 3000.

Verified that this PR's approach fixes it

I applied both changes from this PR to my local 0.45.1 cache and ran the actual hook end-to-end (same stdin payload, only the module swapped):

original : IMPORTANT: The Vercel CLI is not installed.
patched  : (no output)

Impact worth flagging: resolveBinaryFromPath is shared, so checkAgentBrowser() and any other binary probe degrade the same way, and the false "not installed" line is injected into the context of every session on Windows. It is convincing enough to act on — in my case it led to a wrong conclusion that the CLI was unavailable and to work being planned around that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants