Do not resolve unmatched tilde prefixes

expandHomePrefix now wraps the replacement in path.resolve(...), but the regex only replaces ~ when followed by end-of-string or a path separator. Inputs like ~alice/bin/tool therefore remain unchanged by replace and then get coerced into a cwd-relative absolute path (for example /cwd/~alice/bin/tool), which silently changes a non-home token into a different filesystem target. This can mis-resolve command paths and allowlist patterns that start with ~ but are not home-prefix syntax.

Useful? React with 👍 / 👎.

Skip PATHEXT gating for explicit executable files

On Windows this new branch treats a file as executable only if its extension appears in PATHEXT, even for explicit absolute/relative paths. PATHEXT is only meant for extension lookup when no extension is provided; with this change, resolveExecutablePath can reject a real file like C:\...\node.exe whenever the provided environment narrows PATHEXT (for example to .CMD), causing false negatives in command resolution under sanitized/custom envs.

Useful? React with 👍 / 👎.

Case-insensitive regex but case-sensitive formula guard

The regex was made case-insensitive with the i flag, meaning cellarMatch[2] (the formula capture) preserves the original casing from the input path. The formula === "node" guard directly below is a strict equality check — if a path ever contained NODE or Node in the Cellar segment, the fallback to <prefix>/bin/node would be silently skipped.

Homebrew always uses lowercase formula names in practice, so this is unlikely to cause real problems today. But since the regex was intentionally made case-insensitive, a consistent fix would be:

This is a comment left during a code review.
Path: src/infra/stable-node-path.ts
Line: 33

Comment:
**Case-insensitive regex but case-sensitive formula guard**

The regex was made case-insensitive with the `i` flag, meaning `cellarMatch[2]` (the `formula` capture) preserves the original casing from the input path. The `formula === "node"` guard directly below is a strict equality check — if a path ever contained `NODE` or `Node` in the Cellar segment, the fallback to `<prefix>/bin/node` would be silently skipped.

Homebrew always uses lowercase formula names in practice, so this is unlikely to cause real problems today. But since the regex was intentionally made case-insensitive, a consistent fix would be:

```suggestion
  if (formula.toLowerCase() === "node") {
```

How can I resolve this? If you propose a fix, please make it concise.

Custom path join bypasses normalisation

joinStablePath concatenates parts with a raw separator character rather than using path.join (or path.posix.join/path.win32.join). If prefix happens to have a trailing separator (e.g. from cellarMatch[1] ending with /), the resulting path would contain a doubled slash like /opt/homebrew//opt/node/bin/node.

The new regex uses [\\/]+ (greedy, one-or-more), so the lazy (.+?) stops before the first run of slashes, giving a clean prefix in well-formed paths. However, using path.posix.join / path.win32.join (selected by the same nodePath.includes("\\") heuristic) would be more robust:

const join = nodePath.includes("\\") ? path.win32.join : path.posix.join;
const optPath = join(prefix, "opt", formula, "bin", binaryName);

This is a comment left during a code review.
Path: src/infra/stable-node-path.ts
Line: 20-21

Comment:
**Custom path join bypasses normalisation**

`joinStablePath` concatenates parts with a raw separator character rather than using `path.join` (or `path.posix.join`/`path.win32.join`). If `prefix` happens to have a trailing separator (e.g. from `cellarMatch[1]` ending with `/`), the resulting path would contain a doubled slash like `/opt/homebrew//opt/node/bin/node`.

The new regex uses `[\\/]+` (greedy, one-or-more), so the lazy `(.+?)` stops before the first run of slashes, giving a clean prefix in well-formed paths. However, using `path.posix.join` / `path.win32.join` (selected by the same `nodePath.includes("\\")` heuristic) would be more robust:

```ts
const join = nodePath.includes("\\") ? path.win32.join : path.posix.join;
const optPath = join(prefix, "opt", formula, "bin", binaryName);
```

How can I resolve this? If you propose a fix, please make it concise.

Preserve unmatched tilde tokens in home prefix expansion

Wrapping the replacement in path.resolve(...) changes non-home tokens like ~alice/bin into cwd-anchored absolute paths, because the regex only replaces bare ~ or ~/.../~\\... and leaves ~alice untouched. Fresh evidence: callers like resolveAllowlistCandidatePath and resolveExecutablePath then treat that rewritten value as a concrete filesystem path, so an unresolved token can silently target <cwd>/~alice/... instead of remaining unresolved.

Useful? React with 👍 / 👎.

Bypass PATHEXT checks for already-qualified executables

This Windows branch now requires the file extension to be present in PATHEXT even after a concrete file path has already been found, which can reject real binaries such as node.exe under restricted envs (for example PATHEXT=.CMD). Fresh evidence: resolveExecutableFromPathEnv now forwards the caller env into isExecutableFile, so PATH lookups of commands that already include an extension can incorrectly return undefined despite the file existing.

Useful? React with 👍 / 👎.