[Bug] agent-presets.roots user config is overwritten by composeProfile — custom preset roots never take effect

[DRAG0NM]

[Bug Report] agent-presets.roots 用户配置被 composeProfile 强制覆盖，项目级/自定义 preset 根永远不生效

摘要

dsh-agent-presets 文档声称 roots 是可配置项（README 配置表），但 apps/cli 的 composeProfile 在组合完所有 patch 层之后，额外注入一个覆盖层，把 agent-presets 行的 roots 整体替换为只有 shipped root。结果是：用户通过 profile cordis.patch.yml 或 --patch 配置的任何自定义 preset 根永远不会被扫描；只有 includeUserRoot 默认的用户根（$DSH_HOME/.agent-presets）能工作。--dump-config 不含该注入步骤，因此会显示"配置正确"的假象。

复现步骤

1. 创建自定义 preset 根（例如 D:\project\.dsh\agent-presets\my-preset\，内含 agent.cordis.yml + preset.yml）
2. 写 patch 注入 roots：

# test.patch.yml
- id: agent-presets
  config:
    default: standard
    includeUserRoot: true
    roots:
      - path: D:/project/.dsh/agent-presets
        trust: user

3. 启动：npx @deepseek-ai/dsh web --patch test.patch.yml
4. 打开 Web UI → 新建对话 → 预设选择器 → my-preset 不出现

对照：把同一 preset 复制到 $DSH_HOME/.agent-presets/my-preset/（includeUserRoot 默认行为）→ 立即可见。证明 preset 文件本身没问题，问题在 roots 注入。

根因（源码定位）

apps/cli/src/profile-boot.ts（编译产物 lib/profile-boot-DG5t9aNs.js）composeProfile() 第 179-188 行：

if (rows.has("agent-presets")) composedOverlays.push({
    id: "agent-presets",
    config: {
        ...rows.get("agent-presets")?.config ?? {},   // 保留 default/includeUserRoot
        roots: [{                                      // ← roots 被整体替换
            path: SHIPPED_PRESET_ROOT,
            trust: "system"
        }]
    }
});

该覆盖层作为最后的 overlay 传给 loader（composedOverlays），因此无论用户在哪一层配置 roots，最终都会被替换为只有 shipped root。default 与 includeUserRoot 因对象展开得以保留，只有 roots 被覆盖。

为什么 --dump-config 显示"配置正确"

--dump-config 输出的是 patch 层组合结果（bundle + profile + home + --patch），不包含 composeProfile 的运行时注入（注入发生在 dump 之后、loader 加载插件之前）。所以 dump 里能看到用户 roots，但运行时插件收到的 config 已被覆盖。

建议修复

将"替换"改为"追加"，让用户配置优先：

if (rows.has("agent-presets")) composedOverlays.push({
    id: "agent-presets",
    config: {
        ...rows.get("agent-presets")?.config ?? {},
        roots: [
            ...(rows.get("agent-presets")?.config?.roots ?? []),  // 用户配置优先
            { path: SHIPPED_PRESET_ROOT, trust: "system" }        // shipped 兜底
        ]
    }
});

影响

• 所有希望把 preset 放在项目内（随仓库分发、git 管理）的部署场景不可用
• 与官方文档矛盾（dsh-agent-presets README 的 roots 配置表）
• 多项目/多根场景（团队共享 preset 根）完全无法实现

环境

• OS: Windows 11
• dsh 版本: 0.1.0-rc.6（npx @deepseek-ai/dsh，2026-08-14 安装）
• Node: v24.16.0

验证材料

• --dump-config --patch test.patch.yml 输出：roots 配置正确显示（假象）
• 运行时探针（动态插件读 agentPresets.config）：roots 只有 shipped
• 双对照实验：用户根 preset 可见 ✅ / 项目内 roots preset 不可见 ❌

---

Found by community user while building a project-level preset setup. Happy to provide more details or open a PR with the suggested fix.

[crazy3water]

这个问题如何解决呢？
目前遇到问题：

1. 添加工作区，crypto.randomUUID()问题，安装了nginx+openssl+插件（dsh plugin --profile web add dsh-lan-access）
2. 添加模型遇到问题：“加载提供方目录失败: transport failure for /api/settings.describe: HTTP 403”，没有找到解决方案

[DRAG0NM]

这两个现象分属两个已知家族，各有定位：

1. crypto.randomUUID is not a function：浏览器只在 secure context（localhost 或 HTTPS）下提供该 API；经局域网 IP/纯 HTTP 访问时 Web 运行时直接崩溃（[bug]标题:浏览器端 crypto.randomUUID() 在局域网 HTTP 访问下崩溃(非安全上下文),页面无法使用 #514/[Bug report] 通过 `http://<局域网IP>:3080` 访问 Web UI 时，打开文件夹（选择工作区）报"无法打开文件夹" #755/Web UI crashes over plain-HTTP LAN/VPN access: crypto.randomUUID is not a function (secure-context-only API) #980 同族）。
2. /api/settings.describe 403：信任围栏拒绝了不带端口或端口被剥离的 Origin（[Bug] Models settings page returns HTTP 403 when browser sends a port-less loopback Origin #894/BUG: Web GUI via http://127.0.0.1:3080 — every /api call returns 403 (Chrome Origin header omits the port) #910 家族；完整分析见 [Bug Report] 信任围栏误拒绝：Chrome 对回环地址剥离 Origin 端口，`isTrustedApiRequest` 按含端口的 host 精确比较导致 403 #1323）。

建议先用 http://127.0.0.1:3080 本地访问确认功能正常，再按 #1323 的围栏机制调整部署（受信 Host/Origin），或等官方修复。

[naipi11]

遇到同样问题（--patch 里配了 agent-presets.roots，但 Web UI 预设选择器里看不到项目内 preset）时，当前可用的办法是先把 preset 放进用户根目录：<dshHome>/.agent-presets/<preset-name>/（默认是 %USERPROFILE%\.dsh\.agent-presets\，可用 $env:DSH_HOME 改位置）。includeUserRoot 默认开启，这个根是唯一不受 composeProfile 运行时覆盖影响的，放好后重启 Web 服务就能在预设选择器里看到。

项目根要随仓库分发的话，在修复合入前可以把这个目录复制到用户根，或在启动脚本里同步。注意别被 --dump-config 误导：它显示的是 patch 组合结果，运行时还会注入一个覆盖层把 roots 换成只有 shipped 根，所以 dump 里“配置正确”不等于真的生效。

判断是否命中这个 bug：--dump-config --patch test.patch.yml 能看到你的 roots，但 UI 里不出现，就是同一问题。

English: While the runtime roots override is unfixed, place custom presets under /.agent-presets (includeUserRoot is on by default); treat --dump-config as non-authoritative since composeProfile overwrites roots after the dump step.

[taltara]

Corroborating this from the other direction, in case it helps confirm the diagnosis: I ship a tool that writes custom presets (dsh-blueprint, MIT), and it works - precisely because it writes to the default user root and never touches roots.

Concretely, on rc.7: writing $DSH_HOME/.agent-presets/<id>/agent.cordis.yml plus a preset.yml makes the preset appear in the session picker alongside the shipped ones, with no restart. Discovery is unmemoized, so it is selectable the moment the files land. I did not configure roots at all, and I had no idea until reading this that configuring it would have silently done nothing.

So this report matches what I see: the default user root is the one path that works, and it is the one I would tell people to use today.

The detail I would underline for anyone landing here from a broken setup is your last one - --dump-config not showing the injected override. That is the part that costs the most time, because the natural way to check whether config took effect is to dump it, and here the dump agrees with you while the runtime does not. Anyone debugging a custom root will conclude their YAML is correct, because by the composition it is.

If it is useful for a workaround section, the shape that does work:

$DSH_HOME/.agent-presets/
  my-preset/
    preset.yml          # name, description, order
    agent.cordis.yml    # persona row, then one flat row per tool

agent.cordis.yml follows the same shape as the shipped standard preset - a persona row using @deepseek-ai/dsh-persona, then - id: <row> / name: '<package>' per tool. A directory whose composition is unparsable or is not a list of named rows is listed as broken with a reason rather than skipped, which is a genuinely nice touch when authoring by hand.

If it saves anyone the YAML, the compiler that emits this shape is compileGraphToPreset - about eighty lines, MIT, and the tests next to it double as worked examples of the format.

[luria-hebb]

Independent corroboration from a different platform and a different downstream project — same root cause, same fix shape already suggested here.

Setup: macOS, dsh 0.1.1-rc.2, investigating why dsh-engram (a third-party package that mounts a persistent-memory MCP server + skills as an agent preset) couldn't get its preset discovered via roots in cordis.patch.yml.

Same source location, byte-for-byte: profile-boot-DG5t9aNs.js lines 179-187 in my installed CLI, unconditionally overwriting roots with [{path: SHIPPED_PRESET_ROOT, trust: "system"}] regardless of what a bundle/patch already set. Matches the OP's composeProfile() finding exactly — same behavior on a different OS, so this isn't platform-specific.

Confirms --dump-config is non-authoritative for this field, the way @naipi11 and @taltara already flagged: composed cleanly with the custom roots value visible in the dump, but the runtime override happens after that step, so the dump shows intent, not what the loader actually receives.

The includeUserRoot/$DSH_HOME/.agent-presets workaround (@naipi11, @taltara) is the right interim answer, and it's better than what I initially documented for my own package (a copy-into-the-CLI's-shipped-root step, redone on every dsh upgrade). I checked dsh-agent-presets's own source: includeUserRoot defaults to true and appends <dshHome>/.agent-presets as a user root after the roots computation the bug corrupts — so it's structurally immune to this specific override, and unlike a copy into the CLI's own install tree, it lives in user-space and survives a dsh upgrade without needing to be redone. Updating my own docs to recommend that path instead.

Thanks to whoever filed this and to @naipi11/@taltara for the workaround — saved me from shipping a worse one.

[taltara]

Thanks for the byte-for-byte confirmation - that is the detail that settles it.
I can add a third data point: same file, profile-boot-DG5t9aNs.js, same lines,
on 0.1.0-rc.7. So this is stable across 0.1.0-rc.7 and 0.1.1-rc.2, and the
filename hash being identical across those two says the module has not been
touched between them.

Worth spelling out exactly what the override does, because it explains why the
config looks half-respected:

if (rows.has("agent-presets")) composedOverlays.push({
  id: "agent-presets",
  config: {
    ...rows.get("agent-presets")?.config ?? {},
    roots: [{ path: SHIPPED_PRESET_ROOT, trust: "system" }]
  }
});

It spreads your config and then replaces one key. Every other field you set on
that row survives - only roots is discarded. Anyone testing with a row that
sets roots alongside something else will see the something else take effect,
which makes the failure look intermittent rather than total.

On --dump-config being non-authoritative here, one refinement: the override is
pushed onto composedOverlays after the array the dump prints is built, so
the dump is not stale or cached - it is showing a genuinely different value from
the one the loader receives. Nothing you can pass to the CLI will show you the
effective value, which is why this costs people an afternoon.

@luria-hebb - your point about the user root surviving a dsh upgrade is the
part I had not articulated and it is the stronger argument for it. Copying into
the CLI's own install tree loses on every upgrade; $DSH_HOME/.agent-presets
does not, and it is immune here for a structural reason rather than by luck,
since includeUserRoot appends after the computation that gets corrupted.

Since three of us have now lost time to the dump disagreeing with the runtime, I
put the check in the tool rather than only in this thread. dsh-overlay-check
0.4.0 (MIT, no dependencies) refuses to let an overlay claim this silently:

warning  config-silently-overwritten  "agent-presets.roots" is replaced at boot
with the shipped root, so setting it here does nothing — and --dump-config will
still show your value, because the override is applied after the composition it
prints. Put presets in $DSH_HOME/.agent-presets/<id>/ instead.

It is a plain function over patch rows, so it is usable from anything that
writes config, not only from my own tooling:
https://github.com/taltara/mddl-harness/tree/main/packages/overlay-check

Happy to drop the rule the moment this is fixed upstream - it is scoped to this
one row and one key precisely so it can be deleted cleanly.