【Bug】--patch 被用户设置层静默覆盖（silently overridden by user settings layer），--dump-config 报告失真

[superchenwb]

中文

环境

• dsh 0.1.6-alpha.1（npm i -g @deepseek-ai/dsh 安装）
• macOS，Node v24.18.1

期望与实际行为

--help 把 --patch 描述为 "extra patch-list overlay applied after the profile layer"，字面理解应当"覆盖 profile 层"。我期望 --patch 里对 agent-default-model 的覆盖能决定 headless 运行实际使用的模型。

实际发生的是：一旦用户层（~/.dsh/settings.yaml，由 UI 里选择默认模型 / saveSelection 写入）存在 agent-default-model 段，用户层会在运行时静默胜出，--patch 的值被降级为兜底默认值。全程没有任何警告，--json 事件流里也没有任何字段能暴露实际生效的模型。

最小复现

# 1. 用户层：在 dsh UI 里任选一个默认模型，或写入 ~/.dsh/settings.yaml：
#    agent-default-model:
#      provider: kimi-coding
#      model: k3-256k

# 2. 一个请求不同模型的 patch 覆盖层
cat > /tmp/model.patch.yml <<'EOF'
- id: agent-default-model
  config:
    provider: deepseek-official
    model: deepseek-flash
EOF

# 3. 查看组合后的配置
dsh --patch /tmp/model.patch.yml --profile headless --dump-config
# → 显示: agent-default-model: provider deepseek-official, model deepseek-flash

# 4. 跑一次 headless 任务
echo "reply with the single word: ok" | dsh --patch /tmp/model.patch.yml --profile headless --json -

# 5. 核对实际服务的模型——看 ~/.dsh/sessions/**/session.v3.jsonl.zstd 里的会话记录：
# → "provider":"kimi-coding","model":"k3-256k"
# （注入的系统提示词里也能看到："powered by the k3-256k model"）

同样的 CLI 调用，仅仅因为看不见的 global 状态（~/.dsh/settings.yaml）就服务了不同的模型。

根因（来自打包后的插件源码）

@deepseek-ai/dsh-agent-default-model/lib/index.js 把组合树里的配置项作为兜底默认值安装，然后让 settings provider 的用户层在运行时实时替换它：

const entry = { provider: config.provider, model: config.model }; // 组合树的值（--patch 落在这里）
this.source = () => entry;
ctx.inject(["settings"], (settingsCtx) => {
  settingsCtx.settings.installSection(ctx, "agent-default-model", SCHEMA, entry, {
    setSource: (current) => { this.source = current; }, // 用户层替换 source
  });
});
// 注释原文: "when one is mounted, its user layer is read live"

所以优先级是刻意设计的：用户层 > --patch > profile bundles。我理解"用户显式选择优先"对交互式使用是合理的 UX——问题在于对 headless / 自动化场景，这一切都是静默且不可检测的。

为什么这是问题（两个具体缺陷）

1. --dump-config 报告了一个不会运行的配置。 --help 说 --dump-config 打印 "the composed profile tree"，并把它和 --dump-default-config（"without its user layer or --patch overlays"）对比——强烈暗示 --dump-config 包含用户层。实际并不包含：上面第 3 步打印 deepseek-official/deepseek-flash，第 4 步却实际运行 kimi-coding/k3-256k。官方提供的"看生效配置"工具给出了错误答案，排查这种问题非常痛苦。

2. 自动化无法信任自己的注入。 我们用 headless 模式（--profile headless --json）驱动无人值守的修复流水线，并通过 --patch 钉死模型。某天有人在 dsh UI 里设置了默认模型后，我们所有的运行都悄悄迁移到了另一个 provider/model 上。直到预期 provider 的用量面板一片空白才发现。对一个明显面向自动化的 headless/JSON 模式来说，"服务的模型 ≠ 请求的模型、且无任何信号"是最糟糕的失败形态。

建议

• 在 headless --json 事件流里输出实际生效的 provider/model（比如放在 session 事件里），让调用方可以核对；
• 当 --patch 的某项被用户层覆盖时，在 stderr 打警告；
• 让 --dump-config 反映用户层的效果，或新增 --dump-effective-config；
• 在文档里明确写出优先级顺序：用户层 > --patch > profile bundles > 内置默认值。

可提供更多日志或协助测试修复。感谢 dsh 团队的工作！

---

English

Environment

• dsh 0.1.6-alpha.1 (installed via npm i -g @deepseek-ai/dsh)
• macOS, Node v24.18.1

Expected vs. actual

--help describes --patch as "extra patch-list overlay applied after the profile layer", which reads as "wins over the profile". I expected a --patch entry for agent-default-model to determine the model a headless run actually uses.

What actually happens: once the user layer (~/.dsh/settings.yaml, written via model selection in the UI / saveSelection) contains an agent-default-model section, the user layer silently wins at runtime and the --patch value is demoted to a fallback default. There is no warning, and the effective model is not exposed anywhere in the --json event stream.

Minimal repro

# 1. User layer: pick any default model in the dsh UI, or write ~/.dsh/settings.yaml:
#    agent-default-model:
#      provider: kimi-coding
#      model: k3-256k

# 2. A patch overlay requesting a *different* model
cat > /tmp/model.patch.yml <<'EOF'
- id: agent-default-model
  config:
    provider: deepseek-official
    model: deepseek-flash
EOF

# 3. Inspect the composed config
dsh --patch /tmp/model.patch.yml --profile headless --dump-config
# → shows: agent-default-model: provider deepseek-official, model deepseek-flash

# 4. Run one headless task
echo "reply with the single word: ok" | dsh --patch /tmp/model.patch.yml --profile headless --json -

# 5. Check what actually served — the session record under ~/.dsh/sessions/**/session.v3.jsonl.zstd:
# → "provider":"kimi-coding","model":"k3-256k"
# (also visible in the injected system prompt: "powered by the k3-256k model")

Same CLI invocation serves a different model depending on invisible global state (~/.dsh/settings.yaml).

Root cause (from the bundled plugin source)

@deepseek-ai/dsh-agent-default-model/lib/index.js installs the composed config entry as a fallback default and then lets the settings provider's user layer replace it live:

const entry = { provider: config.provider, model: config.model }; // composed tree value (--patch lands here)
this.source = () => entry;
ctx.inject(["settings"], (settingsCtx) => {
  settingsCtx.settings.installSection(ctx, "agent-default-model", SCHEMA, entry, {
    setSource: (current) => { this.source = current; }, // user layer replaces the source
  });
});
// comment: "when one is mounted, its user layer is read live"

So the precedence is by design: user layer > --patch > profile bundles. I understand "user's explicit choice wins" is reasonable UX for interactive use — the problem is the silent and undetectable part for headless/automation use.

Why this hurts (two concrete defects)

1. --dump-config reports a config that will not run. --help says it prints "the composed profile tree" and contrasts with --dump-default-config ("without its user layer or --patch overlays") — strongly implying --dump-config includes the user layer. It does not: step 3 above prints deepseek-official/deepseek-flash while step 4 actually runs kimi-coding/k3-256k. The one tool meant for "what will my config be" gives the wrong answer, which makes debugging this a real pain.

2. Automation cannot trust its own injection. We drive dsh headless (--profile headless --json) from an unattended bug-fixing pipeline and pin the model via --patch. After someone set a default model in the dsh UI, all our runs silently moved to a different provider/model. We only noticed because the expected provider's usage dashboard showed nothing. For a headless/JSON mode that is clearly aimed at automation, "served model ≠ requested model, with no signal" is the worst kind of failure mode.

Suggestions

• Emit the effective provider/model in the headless --json stream (e.g. in the session event), so callers can verify what actually served.
• Print a stderr warning when a --patch entry is shadowed by the user layer.
• Make --dump-config reflect the user layer's effect, or add a --dump-effective-config that does.
• Document the precedence order explicitly: user layer > --patch > profile bundles > built-in defaults.

Happy to provide more logs or test a fix. Thanks for the great work on dsh!

[LegGasai]

感谢反馈，这是一个配置作用域隔离的问题。~/.dsh/settings.yaml 最初是为 Web 端的用户设置引入的，后来 Settings 被挂载到了共享 base，使 headless 也读取了这份设置，并在 profile 配置合成之后再次覆盖模型选择，导致 --patch 和 --dump-config 的结果与实际运行不一致。我们计划将 Settings 的默认挂载限定在 Web，headless 使用合成后的 profile 配置及命令行覆盖，不再受 Web 设置影响。

[sihan-bzwj]

补一个同类案例，说明这不止影响 agent-default-model。

另一个受害 section：agent-presets

环境：dsh 0.1.5-rc.1，Windows，profile web。

# ~/.dsh/settings.yaml（用户层）
agent-presets:
  default: minimal

# dsh --profile web --dump-config（bundle 默认）
- id: agent-presets
  name: '@deepseek-ai/dsh-agent-presets'
  config:
    default: standard        # ← 只显示这个，实际跑的是 minimal

实际会话用的是 minimal preset，而 --dump-config 忠实打印了 bundle 默认的 standard。与你第 3 步同构，只是 section 从模型换成了 preset。

代价：minimal preset 的组合文件显式 includeRuntimeContext: false（@deepseek-ai/dsh-agent-presets/presets/minimal/agent.cordis.yml），会压制全部 runtime context 快照 —— 第三方插件注入、记忆、用户画像，连同宿主内置的沙箱策略 context 一起消失，且对用户静默。而 --dump-config 又反过来暗示一切正常。定位这段花了很久（逐帧解压 session.v3.jsonl.zstd 才确认）。完整排查：slow-stack/mneme#175

一个盲区：计划中的修法不覆盖 Web 场景

上面提到的方向是「把 Settings 的默认挂载限定在 Web，headless 改用合成后的 profile 配置」。这对 headless 是对的，但对 Web 无效 —— 我们这一例恰恰发生在 --profile web，用户层仍然覆盖，--dump-config 也仍然失真。

所以 Web 场景下「--dump-config 给出不会运行的配置」这个问题依然存在。

再次附议

• --dump-effective-config（或让 --dump-config 反映用户层）—— 对 Web 尤其需要；
• 用户层覆盖组合树的值时，在 stderr 打一条警告。

优先级顺序（用户层 > --patch > profile bundles > 内置默认值）确实值得写进文档 —— 目前只能靠读打包源码得知。

[skyloader2474]

我们在无人值守（headless/自动化）面反复踩到同一机制，补三个实证＋一个诉求，供本讨论参考。

实证 1：与本报告同构的 headless 静默降级。 用户层存在 agent-default-model 段时，headless 的显式覆盖被静默降级为兜底值、全程无警告；--dump-config 与事件流无字段暴露实际生效模型——同一调用因不可见的全局状态服务不同模型（本报最小复现已覆盖，此处确认无人值守面同样受害）。

实证 2：委派/subagent 面的同族缺口（shipped 源码）。 dsh-tool-subagent 的 allowedModels 策略只拦显式选择：注释明言 "Pure inheritance remains outside this policy because no model-facing choice occurred"（lib/index.js L83-85），且 assertAllowedModelSelection 在无显式 model 请求时直接早退（L91-98）。即子代理调用省略 model 时纯继承父值、结构性不进策略——显式面有闸门，省略/继承面没有。

实证 3：交互面已有 fail-closed，自动化面没有。 providers 文档对「已保存默认指向已删除 provider」有显式阻断（composer 显示 Select model 并阻止输入）；而无人值守面省略模型时静默回落交互默认。同一语义、两面不一致。

外部同族实案（佐证非孤例）： OpenHands/software-agent-sdk#4494——自动化任务 model=null 致 dispatcher 不设模型、裸调默认解析拿到陈旧模型，两个自动化会话跑错模型并鉴权失败；openclaw/openclaw#74284——cron 式心跳会话的模型钉在创建时刻、不随交互默认漂移（维护者以「按 run 的 effective primary 清理 stale override」修复）。没有一家靠锁交互默认解决此题。

诉求（按优先级）：

1. headless/automation 必须能声明 effective model（如 --model provider/model），且用户设置层不得静默覆盖显式声明；执行后结构化输出应返回 effective provider/model 及其来源层（兼治 dump-config 失真）。
2. 无人值守面未声明模型时应 fail closed（明确报错），而非静默继承交互默认——一句话：headless/automation execution MUST NOT silently inherit interactive session default。
3. 覆盖面建议含委派/subagent 组装层：tool 实例配置层（agentOptions）的默认模型同样不应绕过 allowedModels 静默继承；若短期做不到，至少让 effective 路由及其来源在报告/事件流中可见。

另：看到维护者 2026-09-19 的计划（Settings 默认挂载限定 Web、headless 用合成 profile＋命令行覆盖）——方向完全同意；补充请求是让该隔离覆盖委派/subagent 组装层，并把 effective 路由纳入报告，无人值守面即可闭环。

关于写入完整性（用户设置写盘裁掉无关 namespace）：我们只在机制层确证（整体替换语义），尚未坐实触发条件，不敢妄下断言；若可分单跟踪，愿意补最小复现。

以上结论来自本机两周实测（交互默认 14 天内被重写 9 次、3 次成灾：无人值守任务秒败／漂移／批量投递失败）。需要最小复现细节可以继续补。