描述

在生产环境中，通过设置页安装 Claude/Gemini 等 NPX 类型的 ACP 智能体后，设置页可能显示已经安装，但进入对话页时仍提示对应 CLI 未安装，导致无法连接到智能体。

且注意到开发环境下使用 pnpm tauri dev 启动时通常可以正常识别。

这里我需要说明一下我的 Windows 环境：
我是通过 Scoop 安装 fnm 后，通过 fnm 安装的 node 环境。虽然有点别扭，不过他们的环境变量都是标准且可被正确识别的

相关截图：

由于 OpenClaw/Cline 都一样，所以不全放了

Claude	Gemini

复现方式

1. 首先是和我 Windows 的环境一致...有点小众哥了
2. 在生产版 Codeg 中进入设置页的 “智能体” 分页
3. 安装/重装 Claude 或 Gemini 等 npx 智能体
4. 新建对话页选择对应智能体
5. 提示对应 CLI 未安装，无法开始对话

原因分析

npx 类型智能体依赖 npm 安装后的命令 shim，例如：

claude-agent-acp
gemini

旧逻辑只通过 PATH 查找这些命令。但生产版桌面应用不一定继承用户 shell 环境，npm global prefix 下的 shim 目录可能不在应用进程 PATH 中。

因此会出现：

• npm 包实际已经安装
• shim 文件存在于 npm global prefix

但 codeg 进程通过 PATH 找不到命令，最终误判为 CLI 未安装

影响范围

主要影响 NPX 类型 ACP 智能体，例如 Claude/Gemini/OpenClaw/Cline，

Binary 类型智能体不受影响，例如 Codex 使用 codeg 管理的 binary cache，因此通常可以正常工作。

预期

如果为最小修复，codeg 应在 PATH 查找失败时，尝试通过当前 npm 的 global prefix 查找对应命令 shim，并让设置页状态、连接前检查和实际 spawn 使用一致的命令解析逻辑。

补充

这个问题不是 Codeg v0.11.5 导致的，这个问题困扰了我大约 3 个 Release 版本号。在某次的 Codeg 更新前，我一直是可以正常在 Codeg 使用 Claude/Gemini 的。
但是我刚刚尝试回退了多个 Codeg 版本后，依然无法回到 Codeg 可以正确识别到 Claude/Gemini 的节点。感觉是某一次 Codeg 的 ACP 本地版本更新后，通过 Codeg 设置页更新了这两个模型，由于隐性 bug 导致后续 Codeg 无法正确识别