tool-cordis inspect providers are process-global: two cordis-based presets cannot coexist in one process

[JackieL67]

tool-cordis inspect providers are process-global: two cordis-based presets cannot coexist in one process

Environment

• @deepseek-ai/dsh 0.1.1-rc.2, web profile (dsh web via launchd)
• macOS

Summary

Any two agent presets that both mount tool-cordis (i.e. a user preset copied from the shipped cordis preset via the official copy() authoring path, plus the built-in cordis preset) cannot both mount in the same process. The second one fails with:

agent-presets: preset "<name>" failed to mount:
failed to apply loader entry tool-cordis (@deepseek-ai/dsh-tool-cordis):
Host Cordis inspect provider "Service" is already registered

Only a process restart resolves it, and only if the other cordis-based preset's standing mount is never triggered first.

Steps to reproduce

1. Create a user preset by copying cordis (the "创造模式" / creator-mode preset) through the Agent Preset settings page (agentPresets.copy).
2. Keep tool-cordis in the copied preset (it is copied verbatim).
3. Restart dsh web.
4. In the same process, mount the built-in cordis preset first (e.g. create a session with it, or merely select it on a blank session), then try to create/select a session with the copied preset.
5. The copied preset fails to mount with Host Cordis inspect provider "Service" is already registered. Swapping the order flips which preset fails.

Root cause

• tool-cordis registers four Host inspect providers — Service, Event, Builtin, Tool — unconditionally at mount time (in apply: for (const provider of hostInspectProviders(ctx)) ctx.effect(() => ctx.cordisInspect.register(provider), ...)).
• CordisInspectRegistryService.register() (in @deepseek-ai/dsh-cordis-host-runner) keeps a process-wide singleton providers Map and throws Host Cordis inspect provider "<id>" is already registered on any duplicate id.
• Preset standing mounts are process-lifetime: once a preset's standing mount is created (by any session creation, select, or even a cold transcript read via standingKeyFor), it is never disposed while the process lives (ensureStanding; recompose only re-binds, it does not unmount the previous preset).
• Therefore the first cordis-based preset to be mounted in a process permanently owns all four provider ids, and every other cordis-based preset fails forever until restart.

Impact

• The official authoring path (copy() from a shipped preset) silently produces presets that are mutually exclusive with the shipped cordis preset. The UI gives no hint: the preset merely shows as failing to select / the session falls back to the default preset, while the real error is only visible in the backend.
• Debugging cost is high because the failure looks unrelated to the actual cause: deleting cordis sessions from the UI does not help (standing mounts are in-memory and are not unmounted when sessions are closed/archived), and only a restart followed by mounting the desired preset first works.
• This blocks legitimate use cases such as "a custom cordis-based preset for my workflow, plus the built-in creator mode, in one process."

Community confirmation

The same issue is independently documented by a third-party preset plugin, KannaKuron/dsh-ptc-cordis-preset:

"宿主面 runner 的 inspect 注册表遇重复 provider id 即抛错，是'一个进程只能开一个 cordis 模式会话'的唯一根源"
"关闭/归档会话并不卸载 standing 挂载，所以'现在没有创造模式会话'不代表竞争消失"
"根治仍建议上游把 runner 按会话多实例化"

That plugin ships a shim that monkey-patches the registration to replace duplicates (same-manifest), which confirms the pain is real and widespread.

Suggested fixes (any one)

1. Make the runner per-session / per-preset — instantiate the cordisInspect registry (or at least the host-inspect providers) per preset scope instead of process-global, so multiple cordis-based presets can coexist. (This is the "根治" the community plugin author recommends.)
2. Make registration idempotent — when a provider with the same id and an equivalent manifest is registered again, replace it (returning a disposer that only removes if it is still the current entry) instead of throwing.
3. At minimum, surface the error in the UI — when a preset fails to mount, show the mount error in the preset picker/session creation flow instead of silently falling back to the default preset, so users can diagnose instead of guessing.

Workaround (current)

• Restart dsh web, then create/select the desired cordis-based preset before any other cordis-based preset's standing mount is triggered in the process.
• Do not expect cordis-based presets to coexist; treat them as mutually exclusive per process.

[nokkies]

Confirmed, and the root-cause section is exactly right. I have this fixed locally with a test that fails without it. One warning first, because I think the currently favoured remedy is a trap.

Suggested fix 2 (replace on duplicate) is worse than the throw

The replacing shim the community plugin ships has the same defect. Replacement satisfies the coexistence case and stays broken on disposal ordering:

1. preset A mounts, registers Service;
2. preset B mounts, replaces the entry with its own;
3. B unmounts. Its disposer is the standard "remove if still mine" — and the entry is still B's, so it is deleted.

A is still mounted, still believes it registered four providers, and now has none. cordis_inspect goes dark for a live preset with no error anywhere. That trades a loud, immediate, greppable failure for a silent, delayed, order-dependent capability loss — and the surviving preset is the one that did nothing wrong.

The registrations are interchangeable, which is what makes sharing safe

Worth stating explicitly, because it is the premise the fix rests on and it is not obvious:

• Service, Event and Builtin never touch the mounting ctx at all — they are pure functions over queryServiceApi / queryEventApi / HOST_BUILTIN_INSPECTION, all generated constants;
• Tool is the only one that closes over ctx, as ctx.tools.schemas(context.agent) — and schemas(scope) filters this.view(scope).visible on one shared registry, keyed by the requesting agent from the query context, not by the mounting fiber.

So no provider's answer depends on which preset won the race to register it. That is what makes sharing correct rather than merely convenient.

The shape that works

Keep one entry per id and a set of live holders; remove the entry when the last holder disposes:

const existing = this.providers.get(manifest.id)
if (existing !== undefined && canonicalJson(existing.manifest) !== canonicalJson(manifest)) {
  throw new Error(`Host Cordis inspect provider "${manifest.id}" is already registered`)
}
if (existing === undefined) this.providers.set(manifest.id, { ...registration, manifest })
const holders = this.holders.get(manifest.id) ?? new Set<object>()
const token = {}
holders.add(token)
this.holders.set(manifest.id, holders)
return () => {
  const live = this.holders.get(manifest.id)
  if (live === undefined || !live.delete(token)) return
  if (live.size === 0) { this.holders.delete(manifest.id); this.providers.delete(manifest.id) }
}

Two details that are load-bearing:

• Holder identity, not a refcount. ctx.effect disposers are idempotent by contract, and a counter decremented twice evicts a live survivor — the same silent-loss bug by another route. Deleting an absent set member is already a no-op, so identity buys idempotency for free.
• A different manifest under a taken id still throws. That is the collision the message was written for, so the cordis_stop recipe startHostHalf appends stays meaningful. Comparison is over a key-order-independent serialization, since key order carries no meaning in a manifest.

Against the pre-fix registry, five of six cases fail; the sixth is the genuine-collision throw, which passes both ways by design. The ones that matter are "one holder disposes while another is still mounted" and "a repeated disposer does not drop a live holder" — a replacing or refcounting registry passes the naive coexistence test and fails those two.

On the other two suggestions

Suggestion 1 (per-session runner) is still the real answer for the wider class, and nothing here forecloses it — this only removes the reason a second preset cannot mount today.

Suggestion 3 is worth doing regardless, and independently of this bug. Silently falling back to the default preset is what turned a one-line mount error into a reproduction hunt; a mount failure that reaches the preset picker would have made this self-diagnosing.

[denial123789]

This reproduction exposes two ownership requirements that are easy to collapse into “make registration idempotent.”

1. Equivalence should be checked against a canonical, key-order-independent manifest. Equivalent providers may share one registry entry; a different manifest under the same ID should still fail without replacing the live entry.
2. Each mount needs an opaque holder token. A numeric refcount alone is unsafe if a disposer runs twice; deleting the same token twice is harmless, and the canonical provider is removed only after the holder set becomes empty.

That also covers out-of-order disposal: mount A, mount equivalent B, dispose B, and A must still be able to list/query all four providers. Service, Event, and Builtin do not depend on the mounting preset context; Tool resolves schemas from the requesting agent, so equivalent registrations can safely share once manifest compatibility is proven.

I turned this into a regression matrix and operator runbook, including the separate stale-generation path that reaches the same error: https://sandbaseai.github.io/deepseek-harness-handbook/preset-generation-recovery.html

Disclosure: I maintain the SandBase community handbook.

[weijiafu14]

你和 @nokkies、@denial123789 已经把这条挖得很深了（尤其 @nokkies 那条"replace-on-duplicate 是个陷阱"——A 挂着、B 替换、B 卸载时按'还是我的就删'把 A 的也删了，于是一个活着的 preset 的 cordis_inspect 静默变黑——这个 disposal ordering 的洞很容易被"让注册幂等"这句话盖过去）。

补一件：同一个缺陷在另一条路径上已经被独立报过一次，而且那边的用户可见形态糟糕得多。

#902：同一个注册表，另一个触发器

那位报的是运行中热重载：改 ~/.dsh/profiles/web/cordis.patch.yml（或者更简单——直接改 agent preset 文件），HMR 生效，然后：

点击「新增会话」→ 选择工作区 → 界面闪回"未选择工作区"状态，会话无法创建

他自己定位到的根因和你这条是同一件事：

ensureStanding()：预设文件 stamp 变化时，只删除 standing map 指针、不 dispose 旧代际（源码里有一条未实现的 TODO：reclaim the superseded generation once the last agent joined to it is gone），随后递归重挂载新代际。旧代际在进程级全局 cordisInspect 注册表注册的 Host inspect provider（Service / Event / Builtin / Tool）因此永远不会 unwind。

后端返回的错误一字不差就是你贴的那句：

failed to apply loader entry tool-cordis (@deepseek-ai/dsh-tool-cordis):
Host Cordis inspect provider "Service" is already registered

两份报告合起来说明的是一件事，但角度互补：

	你这条 #4675	#902
触发	两个 cordis preset 在同一进程共存	热重载同一个 preset
你们各自查到的	standing mount 是进程生命周期、recompose 只重绑不卸载	ensureStanding 的那条未实现 TODO
用户看到	明确的挂载失败信息	「新增会话 → 闪回未选择工作区」，界面上一个字都没有

最后一行是我想强调的：#902 那边后端返回了完整的 agent-preset-invalid 错误（preset 名、loader entry、包名、冲突对象、文件路径全都有），而 Web 前端把它扔了。那位为此做了一次逆向工程才找到根因——同一个失败，带报错是十分钟，不带是一整天。

对你这条的意义：修复这个注册表的同时，那个被吞掉的报错也该单独提。否则即使 provider 冲突修好了，下一个 ok:false 的路径仍然会以"界面闪一下"的形式呈现。

一个可能有用的角度：这两条其实指向同一个更上游的选择

你写的"standing mount 是 process-lifetime，一旦创建就永不 dispose"，和 #902 找到的那条 TODO（"等最后一个挂在旧代际上的 agent 消失后再回收"），说的是同一个尚未做出的决定：preset 的挂载什么时候结束？

• 如果答案是"永不"（现状），那么任何注册进进程级注册表的东西都必然是先到先得、且永久占有——你这条就是它的必然结果，不是 tool-cordis 的疏忽；
• 如果答案是"引用计数归零时"，那 @denial123789 说的 holder token 方案正好是它的注册表侧实现，两边可以对齐。

我觉得这个提法对推动有帮助：把"tool-cordis 的注册冲突"归到"preset 挂载生命周期未定义"之下，比作为一个独立 bug 更容易得到一个不会再复发的答案。（否则很可能修完 inspect registry，下一个往进程级注册表写东西的包再撞一次。）

一条通用教训，值得写进结论

@nokkies 那个 disposal ordering 的陷阱，本质是：用"替换"来解决"重复"，会把一个响亮的失败换成一个静默的失败。

这个交换在这个社区里已经出现过好几次，而且每次都是坏交易——最近一例是 #1697：那边的 Symbol.for() 修法解决了同版本双实例，但同时拆掉了不同版本之间的屏障，把"版本错配立刻崩溃"变成"版本错配静默串用"。那边最后的定案是 共享键 + 协议版本守卫——即"让共存成为可能，但让真正的不兼容仍然响亮"。

你这条的正解形状可能是一样的：让等价的注册共享一个条目（@denial123789 的 canonical manifest），但manifest 不同的同 ID 注册仍然响亮失败——他也正是这么说的。这个对照值得引一下，它能帮评审快速理解为什么"幂等/替换"不够。

边界与利益相关

我们不修 DSH 自家组件——tool-cordis、cordis-host-runner 的 inspect registry、agent-presets 的 standing mount 都在 DSH 里。上面全是跨帖串联；我没有复现过你这条（也没用过创造模式预设），#902 / #1697 都是别人的报告。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——但有一句相关的：我们整套挂载都刻意走 agent-local 的 ctx.effect、靠 scope 自动 unwind，就是因为"只要 effect 写进的地方比它自己活得久，忘记 dispose 就不是泄漏、而是直接弄坏下一次加载"。你这条是这句话最干净的例证。

[nokkies]

@weijiafu14 the #902 link is the important addition, and I verified the mechanism against the source rather than taking it on trust. It holds exactly as described:

// TODO: reclaim the superseded generation once the last agent joined to
// it is gone. The subtree is not inert — `dsh-skill-filesystem` watches its
// roots — and the settings-page authoring flow turns "a composition
// changed" into a per-save event.
if (this.standing.get(preset.id) === pending) this.standing.delete(preset.id)
return this.ensureStanding(preset)

The pointer is dropped and the next generation is mounted; the superseded fiber is never disposed, so its ctx.effect registrations — including the four Host inspect providers — never unwind. Same registry, different trigger, and the TODO says in its own words that the leaked subtree keeps working.

Which means I should flag something against my own fix

Holder-set sharing makes #902's error disappear without fixing #902. Once equivalent registrations share one entry, the new generation joins the leaked generation's entry instead of colliding with it, and the mount succeeds. The leak is still there — the superseded subtree still holds its watchers, exactly as that TODO describes.

I think that is still the right trade, but it should be a decision rather than a side effect, so here is the argument both ways.

Why removing it is still right: the collision is a terrible leak detector. It only fires when a second cordis-based preset exists, so the common single-preset case leaks silently today and reports nothing. When it does fire, it does not say "a generation leaked" — it says a preset failed to mount, and blocks the user. A signal that is absent in the usual case, misleading when present, and user-blocking either way is not one worth preserving for its diagnostic value.

What is lost: today, on a two-preset machine, a leaked generation eventually announces itself. After the fix it will not. So the generation leak needs to be tracked on its own merits — the joined-agent count the TODO describes — rather than left to be noticed by a symptom that no longer occurs.

That is worth saying plainly because "the error stopped happening" will be the observable outcome for anyone on #902, and it would be easy to read that as the leak being fixed. It is not.

On the discarded error

Your last point is the one I would act on first, and it is the same thing as suggestion 3 on this thread. The backend produced a complete agent-preset-invalid — preset name, loader entry, package, conflicting object, file path — and the Web client dropped it, leaving "session creation flicks back to no workspace selected" and nothing else. That converted a ten-minute fix into a reverse-engineering exercise, and it will keep doing so for every future mount failure regardless of what causes it, because the discarding is generic.

Both of the causes on these two threads are worth fixing. But surfacing the error is worth more than either, since it is the thing that makes the next unknown one cheap.

@denial123789 your two ownership requirements match what I landed — canonical key-order-independent manifest comparison, and an opaque holder token rather than a numeric refcount precisely because a twice-run disposer must be harmless. Agreed on the out-of-order disposal case being the one that separates a correct fix from a plausible one.

[yamingmou]

Excellent root-cause analysis. Your trace — a process-wide singleton providers Map inside CordisInspectRegistryService.register(), combined with process-lifetime standing mounts that never unmount — is precisely the pattern we flagged in our own audit: state scoped at the module level, with no per-session isolation and no teardown on unload.

It is the same root-cause class as the subagent disposal orphan we reported in #4793 — that missing-lifecycle-handoff-contracts angle is exactly what we'd been digging into on our end. The fix direction implied by your analysis — a per-session / per-mount registry scope instead of a process-global singleton — is the correct one; the real defect is where the ownership boundary is drawn, not the registration call itself.

Glad to see this independently confirmed. It strengthens the case that these are not isolated bugs but a systemic scope-selection problem in how DSH manages cross-module state.

Verified on @deepseek-ai/dsh 0.1.1-rc.2.

---

中文版

非常扎实的根因分析。你追踪到的 —— CordisInspectRegistryService.register() 内部是进程级单例 providers Map，再加上进程级生命周期、永不卸载的 standing mount —— 正是我们自己审计里标记出的模式：状态落在模块级作用域、没有 per-session 隔离、卸载时也无清理。

它和我们报告的子代理 dispose 孤儿（#4793）属于同一类根因，而那个「生命周期交接契约缺失」的角度，正是我们之前一直在抠的。你分析里暗示的修复方向 —— 把注册表作用域从「进程全局单例」改成「per-session / per-mount」 —— 是对的；真正的缺陷在于所有权边界划在哪里，而不在注册调用本身。

很高兴看到这一点被独立证实。它强化了我们的判断：这些不是孤立 bug，而是 DSH 在管理跨模块状态时一个系统性的作用域选择问题。

验证环境：@deepseek-ai/dsh 0.1.1-rc.2.

[nokkies]

A branch carrying a fix for this is available, based directly on cd5ef8148 (0.1.2-alpha.1) so it applies with git am -3:

https://github.com/nokkies/dsh-upstream-patches/tree/fix/cordis-inspect-provider-sharing

It lets two co-resident hosts share an inspect provider id instead of the second registration throwing. Identical manifests share one holder set, and a genuine mismatch still fails loud.

Offered as-is, no attribution wanted. Take, adapt, or ignore it freely.

[Luang2821570856-ops]

Adding cross-version confirmation, a one-line host-side repro, exact code locations, and a suggested fix.

Still reproducible on 0.1.2-alpha.1

The environment in the original report was 0.1.1-rc.2. The same failure reproduces on:

@deepseek-ai/dsh                     0.1.2-alpha.1
@deepseek-ai/dsh-tool-cordis         0.1.2-alpha.1
@deepseek-ai/dsh-cordis-host-runner  0.1.2-alpha.1
@deepseek-ai/dsh-agent-presets       0.1.2-alpha.1
macOS (darwin/arm64), Node v24.19.0, DSH Desktop 2.0.4

Trigger is unchanged: a user preset copied from the shipped cordis preset (via agentPresets.copy, so the tool-cordis row is copied verbatim) plus the shipped cordis preset — the second one to be mounted fails with:

Host Cordis inspect provider "Service" is already registered

Worth noting for scope: of the 8 presets on this machine, only the two containing the tool-cordis row are affected. The other six (standard, ptc, minimal, careful, report, research) mount together without any contention — verified by calling standingKeyFor on each in a process where another preset was already mounted.

One-line host-side repro

No second session and no UI needed — from a process where one tool-cordis preset is already mounted:

await ctx.agentPresets.standingKeyFor('cordis')
// → throws: Host Cordis inspect provider "Service" is already registered

The same call on any preset without that row returns normally. This isolates the failure to the second preset's standing mount (a --dump-config run, which composes only the profile layer, exits 0).

Exact locations

Location	Code
dsh-tool-cordis/lib/index.js:8523	for (const provider of hostInspectProviders(ctx)) ctx.effect(() => ctx.cordisInspect.register(provider), …)
dsh-cordis-host-runner/lib/index.js:721	comment: "Register the process-global Host registry."
dsh-cordis-host-runner/lib/index.js:732	if (this.providers.has(manifest.id)) throw new Error(…)

The row registers four first-party ids — Service, Event, Builtin, Tool — so the first preset to mount owns all four for the process lifetime, exactly as described.

Suggested fix

The provider has no scope dimension in its query surface (cordis_inspect_query(platform, provider, method, input) — provider is the global name from cordis_inspect_list), so it must be process-unique. A second registrant reusing the first one is therefore the correct semantics, not a workaround. Minimal change:

for (const provider of hostInspectProviders(ctx))
  ctx.effect(() => {
    try {
      return ctx.cordisInspect.register(provider);
    } catch (error) {
      // Another preset already registered this process-global provider:
      // it describes process state, so reuse it and do not remove it.
      if (!String(error?.message ?? "").includes("already registered")) throw error;
      return () => {};
    }
  }, `tool-cordis: inspect ${provider.manifest.id}`);

Only the duplicate-registration case is absorbed; every other error still propagates, and the first registrant's behavior is unchanged. Trade-off: the provider now lives until process exit — acceptable here, since "this preset unloaded, so those Services no longer exist" is not a meaningful state. A reference count inside cordisInspect would be stricter but has to handle removal ordering across differently-ordered mounts.

Longer term, this looks like a plane-placement issue: the registration writes into a process-global registry, so it arguably belongs in the host composition rather than being a side effect of a preset row — the preset would then only contribute the cordis_* tools and prompt section, which are scope-registered and contend with nothing.

Minor, but worth fixing either way

The current error text (Host Cordis inspect provider "Service" is already registered) gives the reporter nothing to act on — it does not hint that "you copied the creator preset" is the cause, and per #1827 the UI surfaces nothing at all (the New Session click silently resolves no session). If "one creator preset per process" is the intended constraint, it would help to say so in the error, or to reject it during mount auditing with a readable message instead of failing on a duplicate registration.

I have this patch applied locally and can confirm it parses and is idempotent; I have not yet verified the runtime behavior across a host restart, so treat the fix as a proposal rather than a tested result.

[JokerSuhara]

Postable comment

Confirming this on @deepseek-ai/dsh@0.1.5-rc.1, plus an additional trigger path and a second defect in AgentPresets.ensureStanding

Same root cause as #1415 / #1827 / #2035, so closing this as a duplicate is fine — but two things below are not covered by those reports and both matter for how easy this is to hit.

Environment

• @deepseek-ai/dsh 0.1.5-rc.1
• Windows 11 (26100), Node v25.9.0
• profile web; roster = shipped presets + one user preset
• ~/.dsh/settings.yaml: agent-presets.default: <my copied preset>

Symptom

Clicking New Session does nothing at all — no toast, no error, no new session directory on disk. The Network tab shows the create request completing with HTTP 200 (so this is not an auth or transport failure; the host accepts the RPC and then rejects the composition).

Browser console:

new session failed: SessionCreateError: session create failed: agent-preset/invalid:
agent-presets: preset "cordis-reverse" failed to mount: failed to apply loader entry
tool-cordis (@deepseek-ai/dsh-tool-cordis): Host Cordis inspect provider "Service"
is already registered
    at ClientSessions.create (client.js:3213:1)
    at async Proxy.openWorkspace (client.js:68:1)

The failure reaches the user only as a console.warn:

// @deepseek-ai/dsh-client-ui-workspace/lib/client.js:93-95
this.openWorkspace(target).catch((reason) => {
  console.warn("new session failed:", reason);
});

There is a second silent no-op path in the same handler: when startSession cannot resolve a target workspace it calls this.sessions.clear() and returns (lib/client.js:81-96), which on an already-empty view is indistinguishable from "the button is dead".

Trigger path — the documented preset-copy flow is enough

This does not require a user to deliberately run two cordis toolkits. It is what happens after following the guidance printed in the shipped cordis preset's own header ("To change what a shipped preset does, copy its composition into a new preset directory and edit the copy"):

1. The shipped cordis preset is in the roster and carries - id: tool-cordis
   (@deepseek-ai/dsh-agent-presets/presets/cordis/agent.cordis.yml).
2. The user copies it to .agent-presets/<new-id>/ and edits the persona. The copy still carries tool-cordis.
3. agent-presets.default is pointed at the copy.
4. Sessions created before the copy compose the new default; whichever cordis-family composition mounts first in a given host process takes the four process-global Inspect ids.
5. From then on, every session on the other preset fails to mount — permanently, until the host process restarts.

So a single copy-and-rename turns New Session into a dead button, with no user-visible error.

Second defect: ensureStanding orphans a mount when the composition stamp changes

@deepseek-ai/dsh-agent-presets/lib/index.js:1767-1803:

const pending = this.standing.get(preset.id);
if (pending !== void 0) {
  const mounted = await pending;
  const current = await compositionStamp(preset.path);   // { mtimeMs, size }
  if (current === void 0 || sameStamp(mounted.stamp, current)) return mounted;
  if (this.standing.get(preset.id) === pending) this.standing.delete(preset.id);
  return this.ensureStanding(preset);   // <-- re-mounts; the previous scope is NEVER disposed
}

The stamp-changed branch drops the cache entry and mounts a new generation while mounted.scope stays alive, so every registration the previous generation made is still live. For scope-local registrations that is harmless; for tool-cordis's process-global ones it is fatal — after one stamp change the same preset id can never be mounted again for the rest of the process. Editing the composition file while dsh web is running is sufficient to get here.

Why the existing guard does not catch it

mountPreset rejects rows that publish a process-global service:

// @deepseek-ai/dsh-agent-presets/lib/index.js:920-921
const leaked = leakedServices(agentCtx, fiber);
if (leaked.length > 0) throw new Error(
  `row(s) published process-global service(s) [${leaked.join(", ")}]; a preset service must sit behind an \`isolate\` realm or move to the host composition`);

tool-cordis never publishes a service. It registers into cordisInspect — a process-global service published by @deepseek-ai/dsh-cordis-host-runner at the host plane. There is no equivalent check for that relation, so the preset plane happily accepts a row whose registrations cannot be scoped, and the collision only surfaces later as an unrelated session-creation failure.

Suggested fixes

Any one of these unblocks; the first two are what I would pick.

1. Make the registration idempotent. CordisInspectRegistryService.register
   (dsh-cordis-host-runner/lib/index.js:730-741) currently throws on a duplicate id.
   Upsert for an identical manifest and return the existing disposer, or have tool-cordis
   detect an already-registered id and reuse it.
2. Give tool-cordis a single home. Because cordisInspect is process-global, a
   per-preset home contradicts the plane rule stated in the shipped preset's own header
   ("A row that publishes a service belongs in the host composition"). Ship the row in the
   host composition and drop it from presets/cordis/agent.cordis.yml.
3. Fix ensureStanding to dispose the previous mount before re-mounting on a stamp change.
4. Validate on the preset plane — extend mountPreset/leakedServices to also reject rows
   that register into a process-global registry, so this fails at preset-authoring time with a
   readable message instead of breaking session creation later.
5. Surface the error in the UI. A failed sessions.create should not be a console.warn.

Local workaround I applied

Move the row to the host plane and remove it from the user preset:

• profiles/web/cordis.patch.yml:

  - insert:
      - id: tool-cordis
        name: '@deepseek-ai/dsh-tool-cordis'

• .agent-presets/<copy>/agent.cordis.yml: drop the tool-cordis row.

Then restart dsh web. One caveat: the shipped cordis preset still carries the row, so
after this, selecting that preset for a session fails to mount instead. It trades "my daily
preset is broken" for "a preset I no longer use is broken".

Files (0.1.5-rc.1)

File	Relevance
dsh-tool-cordis/lib/index.js:9095-9113	inject, apply, unconditional ctx.cordisInspect.register(...) for 4 providers
dsh-cordis-host-runner/lib/index.js:716-741	process-global cordisInspect registry; throws on duplicate id
dsh-agent-presets/lib/index.js:1767-1803	ensureStanding re-mount without disposing the previous scope
dsh-agent-presets/lib/index.js:905-938	mountPreset, leakedServices guard (publish-only)
dsh-client-ui-workspace/lib/client.js:81-96	startSession; swallowed rejection and silent sessions.clear()

[PerryLink]

核实结论:报告机制在 master(c291e79)逐点命中,「process-global」论断至今成立;冲突是「preset 挂载生命周期未定义」的必然结果,不是 tool-cordis 的疏忽.

1. 注册方式:tool-cordis 在 apply 里无条件注册四个 Host provider(Service/Event/Builtin/Tool,extensions/tool-cordis/src/index.ts:40-42、providers.ts:26-65);其注入的 cordisInspect 是 cordis-host-runner 在 Host 组合面发布的进程级服务(cordis-host-runner/src/index.ts:138-144). 注册表是实例内 Map(inspect-registry.ts:46),重复 id 即抛(:63)——先挂载的 preset 永久占有四个 id.
2. 多 preset 冲突机制:standing mount 进程生命周期(agent-presets/src/mount.ts:391-393);ensureStanding 在 stamp 变化时只删指针、递归重挂载,旧代际不 dispose(index.ts:788-789,TODO :780-785 原样存在——即 [Bug Report] 运行中热重载 cordis.patch.yml 插入 MCP 插件后，新建会话/选择工作区失败（界面闪回未选择状态） #902 热重载同根因). mountPreset 的 leakedServices 守卫只查「发布」服务(mount.ts:210-224),查不到「注册进进程级服务」这类关系(:407-412),冲突只能晚到会话创建时才爆.
3. Web 端把失败吞成 console.warn + 静默清空(client/ui-workspace/src/client/navigation.ts:165-172)——「新增会话按钮像死了一样」属实.
4. 修复方向排序:① 注册幂等,但要按 nokkies 的 holder-set 形状(等价 manifest 共享条目、真冲突仍响亮抛错;单纯 replace 会因 disposal 顺序把活 preset 的 cordis_inspect 静默弄黑);② 长期答案仍是把该 row 移到宿主组合面,或把注册表按挂载实例化;③ 无论修不修,先把挂载失败显示到 UI. 社区 0.1.2-alpha.1/0.1.5-rc.1 复现与 nokkies 补丁分支未独立复测,但其关键引文已在 master 逐字命中.