Diego Rodrigues de Sa e Souza 70e46f0471 fix(cli): fix Windows CLI detection false negatives (#7753, #7774) (#7831) ...

checkKnownPath() only validated the RESOLVED realpath target against
EXPECTED_PARENT_PATHS, never crediting that the candidate path itself was
already constructed from a trusted root by getKnownToolPaths(). Version
managers that install via symlinks/junctions (nvm-windows and more broadly
nvm/asdf/pyenv-style tools) place the shim inside a trusted root but its
resolved target lives in a private per-version store outside the allowlist,
so it was misreported as symlink_escape (#7753). Fix: trust a candidate
location if EITHER its original path OR its resolved target falls within
EXPECTED_PARENT_PATHS.

Separately, locateCommandCandidate() short-circuited on the FIRST known-path
candidate that returned any non-not_found failure reason, without trying the
remaining candidates or ever falling back to a real PATH search. A single
stray artifact at one guessed Windows install location for claude therefore
poisoned detection entirely even when the real binary was resolvable via PATH
(#7774). Fix: remember non-fatal known-path failures but keep walking every
candidate, and always fall through to the PATH-based search before giving up.

Extracted both helpers into a new cliRuntimeKnownPath.ts module (dependency
injected, no circular import) to keep cliRuntime.ts under its frozen
file-size budget.

2026-07-20 02:03:37 -03:00

14 KiB

Raw Permalink Blame History

View Raw