问题

MCP stdio transport 启动子进程时，如果命令是绝对路径（如 /path/to/wrapper.sh），子进程环境变量 PATH 不包含用户交互式 shell 的完整路径（如 /opt/homebrew/bin），导致 wrapper 脚本中 exec 的子工具（uvx、npx 等）找不到。

报错示例：

plugin "MiniMax": read: EOF: stderr: /path/to/minimax-mcp-wrapper.sh: line 4: exec: uvx: not found

根因

resolveStdioExecutable（internal/plugin/transport_stdio.go）中有三条路径：

shell PATH 探测（defaultStdioShellPATH）的触发条件是"命令未在 PATH 中找到"，但"命令本身能否被找到"和"命令的运行时依赖能否被找到"是两件事。用绝对路径写的命令入口同样需要正确的 PATH 才能让它的子进程正常工作。

此外，macOS GUI 应用（Finder / Dock / open(1)）启动时不继承用户 ~/.zshrc 中配置的 PATH（如 /opt/homebrew/bin），defaultStdioShellPATH 正是为弥补此缺陷而设计的。但它被错误地限定在了"命令未找到"的回退路径中。

修复

将 shell PATH 富化从"命令查找失败的回退路径"提升为 resolveStdioExecutable 中独立的、无条件的初始化步骤。提取了辅助函数 enrichStdioShellPATH，在 hasPathSeparator 检查和 lookPathInEnv 查找之前执行，确保每个 MCP stdio 子进程都继承用户交互式 shell 的完整 PATH。

修复前：

resolveStdioExecutable
  → hasPathSeparator?      → 返回（无 PATH 富化）
  → lookPathInEnv?         → 返回（无 PATH 富化）
  → 都没找到 → 才探测 shell PATH → 再找一次
  → Windows fallback
  → 错误

修复后：

resolveStdioExecutable
  → enrichStdioShellPATH   → 无条件富化 PATH [新增]
  → hasPathSeparator?      → 返回（PATH 已富化）
  → lookPathInEnv?         → 返回（PATH 已富化）
  → Windows fallback
  → 错误

影响范围

• ✅ 使用绝对/相对路径命令的 MCP stdio plugins 获得完整 shell PATH
• ✅ 裸命令名路径不受影响（行为不变）
• ✅ Windows 行为不变（由独立的 windowsStdioFallbackPATH 处理）
• ✅ shell 探测有 2 秒超时保护，无 shell 环境无副作用
• ✅ 向后兼容：现有工作配置不受影响

测试

• 编译通过
• go vet 无警告
• go test ./internal/plugin/ 全部 11 个测试通过