[Bug] 测试链接 npx 类型的 mcp 提示：spawn uvx ENOENT

[shylock-wu]

What happened? / 问题描述

从 MCP 市场安装了 Fetch，点击测试链接的时候报错

Steps to reproduce / 复现步骤

1. 从 MCP 进入市场，安装 Fetch
2. 返回 MCP 列表，测试刚刚安装的 Fetch 会提示错误：spawn uvx ENOENT错误

Expected behavior / 预期行为

应该执行成功，提示没有验证或者验证成功才对

Actual behavior / 实际行为

实际报错：spawn uvx ENOENT

App version / 应用版本

0.15.0

Operating system / 操作系统

macOS

Extra environment / 其他环境信息

No response

Logs / 日志

Screenshots / 截图

[shylock-wu]

分析了下应该是 pi desktop 执行 npx 命令的时候没有找到 npx 的实际位置导致的错误

[vastsa]

感谢反馈 @muzimu217 辛苦看一下哦

[muzimu217]

@muzimu217 不客气，看了一下，根因已定位并在分支上修好：

根因：macOS 上从 Finder/Dock 启动的桌面应用不继承用户 shell 的 PATH（只有 /usr/bin:/bin:/usr/sbin:/sbin），而 npx/uvx 通常装在 nvm/homebrew/用户目录里。MCP stdio spawn 用 shell: false（参数字面化，正确的安全选择）+ 应用进程的最小 PATH，于是 spawn uvx ENOENT。从终端启动应用时不会复现，也与网络/代理无关——与你的观察一致。

修复（分支 feat/mcp-shell-path，基于 #502 之上；待 #502 合并后 diff 即为本修复）：

1. 新增 shell-path.ts：两层 PATH 增强——零探测兜底（追加 homebrew //usr/local//.local//.cargo 等存在目录）+ 登录 shell 探测（execFile $SHELL -ilc echo $PATH，4s 超时静默回退，进程内缓存），两层合并去重；
2. MCP stdio spawn 的 env.PATH 使用增强后的用户 PATH（命令保持裸名，shell: false 的安全语义不变——增强的是查找路径而非执行方式）；
3. 同类隐患一并修：npm 依赖安装器与宿主进程 spawn 也改用增强 PATH（agent 的 Bash 会话里 npx 等用户命令同样受益）；
4. 应用启动即预热探测，宿主启动前就绪；Windows 行为不变。

含单测（路径合并去重/噪声提取/增强段断言），host 552/0、desktop 2081/0、tsc 0。PR 待 #502 合并后开出（届时 diff 即为本修复），或你希望我基于当前分支直接开也可以。

另外反馈一个使用观察：npx 与 uvx 的 ENOENT 会让用户误以为是 MCP 服务本身的问题——修复后若 spawn 仍失败（比如用户确实没装 uv），可以考虑把错误信息带上"可执行文件未找到，请先安装 xxx"的提示，能省一轮排查。

[xiaoqiqiya]

使用playwright，提示spawn npx ENOENT
window ，最新版

[SimonUTD]

[muzimu217]

补充一下两位 Windows 用户报告的 spawn npx ENOENT（@xiaoqiqiya @SimonUTD）——这和 macOS 那次不是同一个根因，分开说：

macOS 面：已在 main 修复

login-shell PATH 方案（ADR 0045 / D600，user-login-path.ts → mcpProcessEnv）已合入，注释里也标了本 issue。我此前在分支上的独立修复覆盖的就是这部分，已被这个实现取代，不再重复提 PR。新版发布后 macOS 的 uvx/npx ENOENT 应该消失。

Windows 面：机理不同，是 .cmd 解析，不是 PATH

代码现状（plugin-mcp.ts）：

• userLookupPath 在 Windows 上直接继承 GUI 进程的 PATH（Windows 没有 login-shell 概念，系统/用户级 env 本来就会被 GUI 继承，这部分合理）；
• 但 stdio spawn 固定 shell: false（正确的安全设计：参数字面化、不经过 shell 解释）。

问题在于 Windows 上的 npx 不是可执行文件，是 npx.cmd 批处理脚本：Node 的 spawn("npx", args, { shell: false }) 在 Windows 上既不会做 PATHEXT 解析、CreateProcess 也不认 .cmd——无论 PATH 里有没有它，结果都是 ENOENT。也就是说 Windows 的这份报告大概率PATH 是通的，卡在解析。

修复建议

spawn 前做一次 Windows 专属的命令解析：

1. 用 where.exe <command>（或按 PATH + PATHEXT 手工探测）把 npx 解析为完整路径（...\npx.cmd）；
2. 解析结果是 .cmd/.bat 时，以 cmd.exe /c <完整路径> <args...> 方式启动——注意这仍然是 argv 数组 + 不拼接自由文本，不引入 shell: true 的注入面，与现有“参数字面化”的安全边界一致；
3. 解析不到时，报错文案里带上探测过的路径清单，比裸 ENOENT 可诊断得多。

临时 workaround（Windows，等修复期间）

在 MCP 条目里不用裸 npx，把命令写成：

命令：cmd.exe
参数：/c npx -y <package>

cmd.exe 是真可执行文件，shell: false 也能直接 spawn。

如果能补充一下各自的 Node 安装方式（官方安装器 / nvm-windows / scoop / volta），可以进一步确认是纯解析问题还是叠加了非标准安装路径——官方安装器场景下 %APPDATA%\npm 一般已在用户 PATH 里，那种情况就纯属 .cmd 解析了。

[vastsa]

复核结论：这是部分已修、部分仍存在的问题。macOS 的 login-shell PATH 已在当前 main 通过 user-login-path.ts → mcpProcessEnv 修复；Windows 报告属于另一根因，plugin-mcp 仍以 shell:false 直接启动 npx/uvx，未处理 npx.cmd/.bat 解析，和 #686 重叠。issue 保持开放。

[muzimu217]

收到复核结论，与我们对 Windows 面的分析一致：是 .cmd/.bat 解析问题而非 PATH。修复方案此前已给过——spawn 前用 where.exe 解析出完整路径，.cmd/.bat 以 cmd.exe /c <完整路径> <args...> 方式启动，仍是 argv 数组、不引入 shell: true 的注入面，与现有参数字面化边界一致；改动收敛在 plugin-mcp.ts 一个文件。你点头我就提 PR（顺带覆盖 #686 的重叠面）。

[muzimu217]

Windows 修复已提 PR：#761。按此前方案——spawn 前经 where.exe 解析裸命令名，命中 .cmd/.bat 时经 %COMSPEC% /d /s /c 启动、参数保持独立 argv（shell 始终 false，无 shell 重解释面）；.exe 直启、解析失败回落既有 ENOENT 报告。解析逻辑 6 例单元测试全覆盖，spec（en/zh）与 e2e 场景已同步。你审的时候顺带看看是否把 #686 一并关掉。