Duplicate registration: [scope] Error: tool "subagent" is already registered in this scope

[w48712616-a11y]

Summary

On some startups the host logs a single [E]. It appears to be a duplicate registration of the subagent tool, and it is reproducible from the factory-default profile (no user configuration involved).

[scope] Error: tool "subagent" is already registered in this scope
  at NamedEntries.duplicateError (…/@deepseek-ai/dsh-tools/lib/index.js:2634:59)
  at NamedEntries.insert (…/@deepseek-ai/dsh-tools/lib/index.js:29:34)
  at layers.effect.label (…/@deepseek-ai/dsh-tools/lib/index.js:2886:62)
  at ScopedLayers.<anonymous> (…/@deepseek-ai/dsh-scope/lib/index.js:206:12)
  at mount (…/@deepseek-ai/dsh-tool-subagent/lib/index.js:398:35)
  at install (…/@deepseek-ai/dsh-tool-subagent/lib/index.js:574:27)

Reproduction

This is not 100% deterministic — observed once on 2026-09-27 01:18:14 and once on 2026-09-29 11:06:52, while a later restart at 11:24 did not log it. Inspect the config tree instead (deterministic):

dsh --profile desktop --dump-default-config   # no user layer at all
# → `- id: tool-subagent` appears 4 times

Current behavior

1. dsh --profile desktop --dump-config lists - id: tool-subagent 4 times.

2. dsh --profile desktop --dump-default-config (no user layer) lists it 4 times as well → unrelated to user config.

3. Grepping shipped bundles' cordis.patch.yml for dsh-tool-subagent:

   • @deepseek-ai/dsh-base — 8 hits
   • @deepseek-ai/dsh-web-app — 6 hits
   • @deepseek-ai/dsh-experimental-agent-team-profile — 4 hits

4. @deepseek-ai/dsh-web-app/cordis.patch.yml:518-532 already suppresses these rows with disabled: true, and the comment acknowledges the collision:

   "…a per-session copy would both starve that host row and collide on the second session. What a preset chooses is which delegation TOOLS its agent sees, below."

   - id: tool-subagent-control
     disabled: true
   - id: tool-subagent-list-agents
     disabled: true
   - id: tool-subagent
     disabled: true
   - id: tool-subagent-fork
     disabled: true

Expected behavior

Either no error is logged, or it is logged at a lower severity — a single benign duplicate-registration notice should not appear as [E] in dsh-*.error.log, where it can mask genuine errors during triage.

Environment

• DSH Desktop 2.0.15 (compatible mode)
• Profile: desktop (custom profile under ~/.dsh/profiles/desktop)
• OS: Windows

Notes

• No functional impact observed: I verified by actually invoking the subagent tool — it returned a normal foreground run. The failing row is the duplicate; the primary registration still serves the tool.
• I did not modify any shipped bundle or the profile's bundle list (dsh-base / dsh-web-app are required bundles and get rewritten by the launcher anyway).
• Happy to provide the full --dump-config / --dump-default-config output or host logs if that helps.

[malyjacob]

这个栈应该和 #6166、#6751 是同一处。mount → install → NamedEntries.insert（tool-subagent/lib/index.js:398 / :574）正好对着 src 里的 mount() 注册和 installScoped 那条 inject 路径，重名的落点就在这。

0.2.0-rc.2 上切 preset 时我也撞到同一个地方，不过表现不是报错而是静默地少工具：切换后的会话只有 13 个，缺 subagent 和 list_subagent_models，同一 preset 直建的是 15 个。原因是 installScoped 先写缓存、后执行，inject() 的回调要等 cordis _reload() 里的 await Promise.resolve() 才跑，异常又被收进子 fiber 的 logger；再加上 recompose() 把 emit('tools/change') 包在 try/catch 里只打 warn。所以这次重名根本不会浮到用户面前，切换照样报成功，只能从 request/header 里数工具数量才发现。你这里能看到 [E] 栈，其实已经比大多数人运气好。

交叉引用：#6751 的这条评论有完整定位 #6751 (comment)

另外你提到 --dump-default-config 里 - id: tool-subagent 出现 4 次——那是 desktop profile 多层叠加导致的，和「第二个会话碰撞」是不同的触发路径，但落在同一个作用域对象上，建议分开记一笔，免得修了一边以为另一边也好了。

[Vsonic12138]

需要修正一下原帖的结论：这里报的重名在宿主里同时存活多个 @deepseek-ai/dsh-tool-subagent 组合时，并不是一条无害的启动期日志，而是会让每一次新建会话都失败（DSH Desktop 0.2.0-rc.2）：

gateway/internal: failed to create session "session-…": Error: tool "subagent" is already registered in this scope

本机可确定性复现，条件是有 6 个存活的组合：内置 standard / cordis / ptc（这三份预设的 spawn 行都带 modelSelectionSettings: true）+ dsh-wsl-workspace@0.7.7 生成的 wsl-standard / wsl-cordis / wsl-ptc 三个变体（它复制源 preset 的 composition，因此也各带一份 delegation 行）。已存在的会话不受影响，只有新建会话失败——所以故障不会自动暴露，只会表现为"新会话开不出来"。

落点来自 ctx.on('agent/created', …) 这条路径：它缺少 reconcileComposedAgents() 具备的 belongsToComposition 门，并且去重表以 Agent 对象身份为键——agent/created 载荷里的对象不是 agents.list() 返回的那个对象，于是同一个 Agent 作用域被注册了两次。

插桩后的完整时序、根因与已验证的最小修复：#6751 (comment)

另外，原帖里混了两件不同的事：--dump-config 里 - id: tool-subagent 出现 4 次是多层叠加的结果，与这个"第二个会话碰撞"无关——正如下面那条评论所说，建议分开记，免得修了一边以为另一边也好了。