[Bug]: mcode 默认不走系统代理，导致 provider test 在仅有代理出口的机器上固定 10000ms 超时

[yxd0379]

Product or interface

CLI - interactive TUI

Version

0.4.12

Platform

Linux

OS version and architecture

openEuler 24.03 (LTS-SP1) aarch64

Issue area

Startup / install / update

Desktop log upload ID (optional)

No response

Steps to reproduce

这是一个代理不支持的常见问题，如果用国外 API BYOK 的方式就会触发问题。

我们机器仅有代理出口，所以同样触发了这个问题。但是这个问题并不只是在这里触发。MiniMax 给 FrontierHarness Eval 的 PR 中也提到了这一问题。这是一个普适性问题。

$ echo $http_proxy;echo $https_proxy;echo $socks_proxy;
http://127.0.0.1:7890
http://127.0.0.1:7890


$ mcode provider add \
  --name "ds4.1flash" \
  --base-url "https://api.deepseek.com/anthropic" \
  --api-format anthropic-messages \
  --model "deepseek-flash[1m]" \
  --use

$ mcode provider test provider-7b0fdd --model deepseek-flash
Provider test failed: Request timed out after 10000ms. Check the URL, API key, and model ID, then retry.

使用 MiniMax 给 FrontierHarness Eval 的 PR 中类似的 proxy-adapter 可以解决

// file: /tmp/mcode-proxy.cjs
const { EnvHttpProxyAgent, setGlobalDispatcher } = require('/tmp/mcode-proxy/node_modules/undici');
if (!process.env.HTTPS_PROXY && !process.env.HTTP_PROXY) {
  throw new Error('HTTP(S)_PROXY is required');
}
setGlobalDispatcher(new EnvHttpProxyAgent());

$ NODE_OPTIONS='--require=/tmp/mcode-proxy.cjs' \
  mcode provider test provider-851e29 --model deepseek-flash --json
{
  "success": true,
  "status": {
    "state": "available",
    "lastTestedAt": 1789782605854
  }
}

$ NODE_OPTIONS='--require=/tmp/mcode-proxy.cjs' \
  mcode exec --cwd /tmp --permission off --max-steps 2 --timeout 45s \
  --output-format json \
  --model custom_provider:provider-851e29/deepseek-flash \
  'Reply with exactly OK and do not inspect or modify any files.'

{"status":"succeeded","output":"OK","model":{"providerId":"custom_provider:provider-851e29","modelId":"deepseek-flash","protocol":"openai-completions"},"durationMs":1247}

Expected and actual behavior

期望行为：mcode 支持代理，避免代理情况下超时报错发生。

Redacted error summary

Screenshots

Before submitting

• I have searched existing issues.
• I have included my version and removed sensitive information.

[hetaoBackend]

感谢提供环境和对照结果。我已单独开始排查：当前公开源码已有大小写 HTTP_PROXY/HTTPS_PROXY、ALL_PROXY 和 NO_PROXY 的处理，因此需要核对 0.4.12 发布包、启动入口，以及 provider test/exec 实际是否走了同一条代理链路。

目前示例前后的 provider ID 和协议输出并不完全相同，我会用同一 provider 配置加本地可观测代理做回归验证，区分发布包差异与当前代码缺陷。后续在这里补充验证结论和可用的修复 PR；暂不把 10 秒超时直接归因于某一个原因。

[hetaoBackend]

已完成公开 npm 产物与当前源码的隔离对照，确认了一个 npm 0.4.12 与 Node 26 的代理兼容问题；当前 main 在本地验证中已正常。原报告尚未提供 Node 版本，因此还不能直接认定报告机器命中的就是这一条原因。

验证使用合成 API key、本地 HTTP/HTTPS mock provider 和可记录请求的 HTTP 代理；阻断了其他实际出站连接，没有调用真实云模型。npm tarball 的 SHA-512/SHA-1 均与公开 registry 元数据一致（SHA-1：2a1e9e59de3cc9955c4df0a7aa6a3c7c4233d5e4）。

• npm 0.4.12 + Node 26.4.0（内置 Undici 8.5.0）：保持同一个 provider ID、模型、URL 和 openai-completions 协议，设置小写 http_proxy / https_proxy 后，provider test 和 exec 都未向代理发送目标请求，socket 记录显示尝试直连。仅增加自行编写的 Undici 8.10.2 EnvHttpProxyAgent 预加载后，两条命令均成功，代理记录到目标 CONNECT，mock provider 收到请求。
• 机制证据：npm 包启动时把代理写入 Symbol.for('undici.globalDispatcher.1')，其所用的 bundled Undici 没有 install()。首次使用 Node 26 内置 fetch 时，内置 Undici 初始化 .2 为直连 Agent，并把 .1 改成兼容 wrapper，覆盖此前的代理配置。记录到了这一完整顺序。因此“源码里有代理初始化”不足以证明该发布产物与所有支持的 Node 版本兼容。
• Node 24.11.1 对照：同一 npm 包的 CLI 启动代理初始化 + 全局 fetch 探针成功经过代理；当前源码构建产物在 Node 24.11.1 / 26.4.0 的同一启动探针均成功。这里 Node 24 仅验证启动/fetch 路径，未运行完整 provider/exec 场景。
• 当前 main e3724a13d72d61c9bdc68a1a72b5c020f065ba26：依赖声明已使用 Undici 8.10.2，代理初始化同时设置 dispatcher 并安装匹配的 fetch。macOS arm64 / Node 26.4.0 下，12 组本地场景的 provider test 与 exec 全部通过：大小写 HTTP(S)_PROXY / ALL_PROXY、仅 HTTP_PROXY 时的 HTTPS 回退、大小写 NO_PROXY、本地地址绕过，以及 OpenAI Completions / Anthropic Messages。检查了 HTTP 代理转发或 HTTPS CONNECT，以及绕过场景没有目标代理请求。

干净的上述 HEAD 上，完整 pnpm verify 的 14 个门禁全部通过。验证进程清除了宿主代理变量，避免混入 #171 的已知离线测试隔离问题；#172 不属于生产代理修复。本轮没有修改源码、创建重复 PR、关闭 issue 或发布版本；公开 npm latest 当前仍为 0.4.12，源码验证通过不代表 npm 已交付修复。

边界：未验证 openEuler aarch64、Windows、真实 DeepSeek 或报告中的实际代理。由于本地探针主动拒绝直连，provider test 返回的是 network 错误，并没有声称复现报告中的精确 10000ms 超时；10000ms 本身是连通性测试的固定 deadline。原示例前后的 provider ID / 协议不同，也未当作严格同请求对照。

请补充运行 mcode 的同一终端中的 node -p 'JSON.stringify({node:process.version,undici:process.versions.undici})'，以及预加载 adapter 所安装的 undici 版本（无需 API key 或完整配置），以确认是否命中上述版本组合。即使是 Node 24，也需要结合实际 Node 小版本及其内置 Undici 判断，不能仅凭主版本下结论。

[yxd0379]

$ node -p 'JSON.stringify({node:process.version,undici:process.versions.undici})'
{"node":"v22.23.2","undici":"6.28.0"}

@hetaoBackend

[hetaoBackend]

感谢补充，已用完全相同的 Node v22.23.2 / 内置 Undici 6.28.0 跑完真实 provider test 和 exec 对照，确认 npm 0.4.12 在这个版本组合下也会丢失代理。需要更正我上一条结论：这不只限于 Node 26。

本轮使用 macOS arm64、本地 HTTPS mock provider、可记录 CONNECT 的 HTTP 代理及合成 key。每次 A/B 保持同一个 provider ID、模型、URL、协议和数据目录，只增加预加载 adapter；其他出站连接均由探针或本地代理拒绝。

Node 22.23.2 下的产物 / 配置	provider test	exec	目标代理 CONNECT
npm 0.4.12，无 adapter	失败，network	失败 / 超时	0，记录到目标直连尝试
同一 npm 产物，加 Undici 8.10.2 EnvHttpProxyAgent 预加载	成功	成功，返回 mock 文本	有
当前 main 81b666a10bb1bd097633b373679dbf399278b8d3 构建，无 adapter	成功	成功，返回 mock 文本	有

上述 A/B 分别验证了 anthropic-messages 和 openai-completions；main 另外验证了大写与小写 HTTP(S)_PROXY，4 组场景的两条命令全部通过。npm 产物关键 JS 文件已与校验过的 0.4.12 tarball 逐字节核对（SHA-1：2a1e9e59de3cc9955c4df0a7aa6a3c7c4233d5e4）。

根因证据：0.4.12 的启动代理写入 undici.globalDispatcher.1；随后加载 provider/runtime 时，包内另一份 bundled Undici 初始化 undici.globalDispatcher.2 为直连 Agent，并把 .1 替换为兼容 wrapper，覆盖了之前的代理。Node 22 这次的写入调用栈指向 npm 包自己的 chunks/chunk-X5PAB4UH.js，并非 Node 内置 Undici。因此 process.versions.undici 不能代表产物内所有 Undici 实现；只测启动后的 fetch、未加载完整 runtime，也会漏掉这条路径。

当前公开源码的 CLI 依赖已与 runtime 侧统一到 Undici 8.10.2，代理初始化同时安装匹配的 fetch。本轮验证未发现需要重复提交的源码修复；npm latest 仍是上述 0.4.12，源码通过不等于发布修复已经交付。此 issue 继续保留，待后续发布产物复验。

边界：未验证 openEuler aarch64、真实 DeepSeek 或你的实际代理；已确认的是发布包在相同 Node 版本上的代理丢失及其机制，不声称已在你的机器完成验收。本地探针主动拒绝直连，所以 provider test 返回 network，而非复现精确的 10000ms deadline；没有据超时数字归因网络。本轮完成 pnpm build 和上述产物对照，未重跑完整 pnpm verify，没有修改源码或创建 PR。

[LiXiaoyao2]

感谢补充，已用完全相同的 Node v22.23.2 / 内置 Undici 6.28.0 跑完真实 provider test 和 exec 对照，确认 npm 0.4.12 在这个版本组合下也会丢失代理。需要更正我上一条结论：这不只限于 Node 26。

本轮使用 macOS arm64、本地 HTTPS mock provider、可记录 CONNECT 的 HTTP 代理及合成 key。每次 A/B 保持同一个 provider ID、模型、URL、协议和数据目录，只增加预加载 adapter；其他出站连接均由探针或本地代理拒绝。

Node 22.23.2 下的产物 / 配置	provider test	exec	目标代理 CONNECT
npm 0.4.12，无 adapter	失败，network	失败 / 超时	0，记录到目标直连尝试
同一 npm 产物，加 Undici 8.10.2 EnvHttpProxyAgent 预加载	成功	成功，返回 mock 文本	有
当前 main 81b666a10bb1bd097633b373679dbf399278b8d3 构建，无 adapter	成功	成功，返回 mock 文本	有

上述 A/B 分别验证了 anthropic-messages 和 openai-completions；main 另外验证了大写与小写 HTTP(S)_PROXY，4 组场景的两条命令全部通过。npm 产物关键 JS 文件已与校验过的 0.4.12 tarball 逐字节核对（SHA-1：2a1e9e59de3cc9955c4df0a7aa6a3c7c4233d5e4）。

根因证据：0.4.12 的启动代理写入 undici.globalDispatcher.1；随后加载 provider/runtime 时，包内另一份 bundled Undici 初始化 undici.globalDispatcher.2 为直连 Agent，并把 .1 替换为兼容 wrapper，覆盖了之前的代理。Node 22 这次的写入调用栈指向 npm 包自己的 chunks/chunk-X5PAB4UH.js，并非 Node 内置 Undici。因此 process.versions.undici 不能代表产物内所有 Undici 实现；只测启动后的 fetch、未加载完整 runtime，也会漏掉这条路径。

当前公开源码的 CLI 依赖已与 runtime 侧统一到 Undici 8.10.2，代理初始化同时安装匹配的 fetch。本轮验证未发现需要重复提交的源码修复；npm latest 仍是上述 0.4.12，源码通过不等于发布修复已经交付。此 issue 继续保留，待后续发布产物复验。

边界：未验证 openEuler aarch64、真实 DeepSeek 或你的实际代理；已确认的是发布包在相同 Node 版本上的代理丢失及其机制，不声称已在你的机器完成验收。本地探针主动拒绝直连，所以 provider test 返回 network，而非复现精确的 10000ms deadline；没有据超时数字归因网络。本轮完成 pnpm build 和上述产物对照，未重跑完整 pnpm verify，没有修改源码或创建 PR。

好奇你是真人还是AI呀