环境变量优先级与文档不一致，系统环境变量覆盖了 `settings.json` 的配置 / system env overrides settings.json config

[06FallingLight90]

问题描述

操作系统信息

• 版本：Windows 11 家庭中文版
• 版本号：23H2
• 安装日期：2024/8/3
• 操作系统版本：22631.6199
• 体验：Windows 功能体验包 1000.22700.1108.0

问题现象

我在 ~/.mini-code/settings.json 中配置了 Xiaomi Mimo 的 URL，同时系统环境变量中配置了 DeepSeek 的 URL。
实际运行时发现，最终生效的 URL 是系统环境变量中的 DeepSeek 地址（而模型名和 Token 却使用了 settings.json 中的配置）。

预期行为

根据 USAGE.md 中说明的配置优先级：

1. ~/.mini-code/settings.json
2. ~/.mini-code/mcp.json
3. 项目级 .mcp.json
4. 兼容的本地已有配置
5. 当前进程环境变量

因此，~/.mini-code/settings.json 中 env 对象内的 ANTHROPIC_BASE_URL 应该优先于系统环境变量中被采用，但实际结果正好相反。

根本原因

源码 src/config.ts 第 205‑208 行：

const env = {
  ...(effectiveSettings.env ?? {}),  // 先放 settings.json 的 env
  ...process.env,                     // 再放系统环境变量 → 覆盖前者！
}

这里对象展开的顺序导致 process.env 永远会覆盖 settings.json 中同名的环境变量，与文档承诺的优先级相反。

修复建议

交换两行代码顺序，使 settings.json 中的 env 拥有更高优先级：

const env = {
  ...process.env,
  ...(effectiveSettings.env ?? {}),  // 后放，让 settings.json 显式配置覆盖系统环境变量
}

Description

System information

• Edition: Windows 11 Home Chinese
• Version: 23H2
• Install date: 2024/8/3
• OS build: 22631.6199
• Experience: Windows Feature Experience Pack 1000.22700.1108.0

Observed behavior

I configured the Xiaomi Mimo API URL inside ~/.mini-code/settings.json, while the DeepSeek URL was set in the system environment variables.
At runtime, the URL from the system environment variables (DeepSeek) took effect – however, the model name and token from settings.json were used, which is inconsistent and confusing.

Expected behavior

According to the documented priority in USAGE.md:

1. ~/.mini-code/settings.json
2. ~/.mini-code/mcp.json
3. Project-level .mcp.json
4. Compatible local existing config
5. Current process environment variables

Therefore, the ANTHROPIC_BASE_URL defined inside env in ~/.mini-code/settings.json should take precedence over the system environment variable, but the opposite happened.

Root cause

In src/config.ts, lines 205‑208:

const env = {
  ...(effectiveSettings.env ?? {}),  // settings.json env first
  ...process.env,                     // system env last → overwrites the former!
}

The object spread order means that process.env always overrides any identically named variable from settings.json, contradicting the documented priority.

Suggested fix

Swap the two lines so that explicit configuration in settings.json wins:

const env = {
  ...process.env,
  ...(effectiveSettings.env ?? {}),  // settings.json env last → takes precedence
}