[feat request] 主进程launch时自注入NODE_USE_ENV_PROXY,使得llm-pi-ai可以走代理端口

[yceachan]

1. 问题

在子代理/工作流中以 gpt-5.6-luna（Luna 5.6）运行任务时失败：

OpenAI API error (403): {"message":"Upstream request failed: [403] This model is not available in your region."}

curl 直连同一 endpoint + 同一 key 却返回 200。

2. 根因

LLM 调用链（全部在 DSH 主进程内）：

llm-pi-ai (config.ts → provider.ts)
  → pi-ai@0.84.1 createProvider / openai-responses API
    → openai-node SDK v6 (new OpenAI({apiKey, baseURL, ...}))
      → Node 全局 fetch (undici) —— 直连，不读代理 env

• Node/undici 默认忽略 HTTP_PROXY/HTTPS_PROXY 环境变量；只有
  NODE_USE_ENV_PROXY=1（Node ≥ 22.15 / 24）或 --use-env-proxy 才启用
  EnvHttpProxyAgent。
• 主进程 env 虽已导出 http_proxy/https_proxy=http://127.0.0.1:7897（Clash），
  但未启用 env-proxy 时全部 LLM 请求直连。
• undici 直连的出口对 opencode.ai 上游被地区拒绝（403）；经 7897 代理出口
  则放行（200）。curl 直连成功是因为 curl 与 undici 的 TLS 请求特征不同，
  被网关区别对待——不影响结论。
• 主模型 deepseek-v4-flash 不受地区限制，所以此前一直正常；luna 一用即暴露。

3. 实测矩阵（同 key、同 endpoint、同模型 gpt-5.6-luna）

路径	结果
undici 直连（修复前 harness 行为）	403 地区错误
curl 直连 / -x http://127.0.0.1:7897	200
undici ProxyAgent('http://127.0.0.1:7897')	200
Node --use-env-proxy	200
NODE_USE_ENV_PROXY=1 环境变量	200

4. 解决方案

1. 临时方案 : launch DSH 时加 NODE_USE_ENV_PROXY=1：
   NODE_USE_ENV_PROXY=1 $DSH_SOURCE/apps/cli/lib/bin.js web
2. bin.ts自注入NODE_USE_ENV_PROXY=1：

#apps/cli/src/bin.ts
if (process.env.NODE_USE_ENV_PROXY === undefined
  && (process.env.HTTP_PROXY !== undefined || process.env.HTTPS_PROXY !== undefined)) {
  process.env.NODE_USE_ENV_PROXY = '1'
}

• NODE_USE_ENV_PROXY 在 Node 首次 fetch 时惰性
  读取，进程内设置与 launch 设置同样生效（均 200），故此处注入时机安全；

[manfonly]

补充一个复现案例，验证同样的根因，且暴露面更广一些。

环境：企业网络出口是一个强制走 HTTP(S) 正向代理的环境（HTTP_PROXY/HTTPS_PROXY
已在系统环境变量里配置好，NO_PROXY=localhost,127.0.0.1），不是本地 clash/v2ray
那种代理，是标准的企业出口代理。

配置：llm-pi-ai 里配了一个 api: openai-completions 的自定义 provider（阿里百炼 DashScope
的兼容模式端点），不是官方 openai-responses/codex 那条路径。

现象：模型请求直接卡住直到超时，被 dsh-llm-retry 归类成 TIMEOUT/TRANSPORT，重试 2
次后失败，UI 上就是「已重试模型请求 (2/2)」。

排查：追到 @earendil-works/pi-ai/dist/api/openai-completions.js，发现它构造 OpenAI
客户端时（new OpenAI({ apiKey, baseURL, dangerouslyAllowBrowser: true, defaultHeaders })）完全没有走 pi-ai 自己那套代理解析逻辑（utils/node-http-proxy.js 的
resolveHttpProxyUrlForTarget）。搜了一下 dist 目录，这个代理解析工具只被
openai-codex-responses.js 和 bedrock-converse-stream.js 引用，openai-completions.js
完全没用到——也就是说任何走 api: openai-completions 的 provider route