tool-cordis inspect-provider registration breaks mounting the shipped cordis agent preset (default)

[Anmulzhao]

tool-cordis inspect-provider registration breaks mounting the shipped cordis agent preset (default)

Summary

In a fresh dsh web process, the first attempt to mount the shipped cordis
agent preset (the deployment default) fails with
agent-preset-invalid: Host Cordis inspect provider "Service" is already registered.
Mounting any other preset that includes tool-cordis first (e.g. a
user-authored preset that copies cordis) leaves cordis permanently broken
for the lifetime of the process.

This is reproducible on the current deployment and silently breaks the UI
"New Session" button — the click resolves no session and no error toast is
shown to the user.

Reproduction

Start dsh web and issue an RPC creating a session with the shipped
cordis preset:

POST /api/session.create
Content-Type: application/json

{
  "type": "client-request",
  "rpcId": "r1",
  "method": "session.create",
  "payload": {
    "workspaceId": "<your-workspace>",
    "agentPreset": "cordis"
  }
}

Response:

{
  "ok": false,
  "error": {
    "code": "agent-preset-invalid",
    "message": "agent-presets: preset \"cordis\" failed to mount: failed to apply loader entry tool-cordis (@deepseek-ai/dsh-tool-cordis): Host Cordis inspect provider \"Service\" is already registered",
    "details": {
      "agentPreset": "cordis",
      "reason": "failed to apply loader entry tool-cordis (@deepseek-ai/dsh-tool-cordis): Host Cordis inspect provider \"Service\" is already registered"
    }
  }
}

Comparing all shipped presets on the same fresh process:

Preset	First session.create	Notes
standard	ok	does not include tool-cordis
minimal	ok	does not include tool-cordis
code	ok	does not include tool-cordis
cordis	fail	shipped default; contains tool-cordis
(custom)	ok	user preset, also contains tool-cordis

If a custom preset is mounted first (it succeeds), cordis cannot be
mounted later in the same process — every subsequent attempt fails with
the same error.

The browser UI silently absorbs the failure: connectWorkspace rejects but
no toast is rendered, so the user sees "click New Session -> nothing happens."

Root cause

@deepseek-ai/dsh-tool-cordis/lib/index.js:6495 registers four Host inspect
providers (Service, Event, Builtin, Tool) into the host plane's
CordisInspectRegistryService:

for (const provider of hostInspectProviders(ctx))
  ctx.effect(() => ctx.cordisInspect.register(provider),
             `tool-cordis: inspect ${provider.manifest.id}`);

CordisInspectRegistryService.register
(@deepseek-ai/dsh-cordis-host-runner/lib/types/inspect-registry.js:20-30)
is not idempotent across fibers:

register(registration) {
  const manifest = validateManifest(registration.manifest);
  if (this.providers.has(manifest.id))
    throw new Error(`Host Cordis inspect provider "${manifest.id}" is already registered`);
  ...
  return () => {
    if (this.providers.get(manifest.id) === stored)
      this.providers.delete(manifest.id);
  };
}

The service instance is process-global (the host registers it once via
ctx.reflect.provide), but its providers Map has no fiber-scoped cleanup.
The disposer returned by register() does run when the originating fiber
disposes -- but as long as any session whose preset contains tool-cordis
remains live in the process, its effect keeps the provider registered, and
no later mount of a preset that also contains tool-cordis can succeed.

The shipped cordis preset attaches tool-cordis at the preset root with
no realm isolation:

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

Meanwhile cordis.yml itself documents the rule that a service-publishing
row either belongs in the host composition or sits inside an isolate
realm (see the comments around agent.cordis.yml:9-12 and :25).
tool-cordis violates that rule: it mutates a host-plane Service's
internal state from a preset, without going through isolate.

@deepseek-ai/dsh-agent-presets/lib/types/mount.js:161 (leakedServices)
is meant to catch preset rows that publish process-global services, but
only inspects Service registration -- it does not flag mutations of an
already-registered Service's internal state, which is exactly what
tool-cordis does.

Expected behavior

• The shipped cordis preset, being the deployment default, must be
  mountable in a fresh process without any prior session creation.
• Two presets that both include tool-cordis should be able to coexist in
  the same process (whether serially or concurrently).
• A failed preset mount should surface a user-visible error in the web UI
  -- silent failure makes this class of bug invisible.

Suggested fix directions

(Any of these is independently sufficient; the third is the smallest
change.)

1. tool-cordis should not register its Host inspect providers as a
   preset row. Move the four registration(...) calls into
   dsh-cordis-host-runner's apply, so they run once on host startup,
   not on every preset mount.

2. Or: have tool-cordis register through an entry-local isolate
   realm, mirroring the pattern cordis.yml itself documents for
   service-publishing rows.

3. Or: make CordisInspectRegistryService.register idempotent across
   fibers -- if the same manifest.id is already present, return the
   existing disposer instead of throwing. This is the smallest code
   change but treats the symptom rather than the cause.

4. Also: SessionRuntime.create rejects with a SessionCreateError
   that the web UI swallows. The shell's startSession /
   connectWorkspace path should propagate the error to a visible toast
   -- silent failures here are user-hostile.

Impact

• New users on the shipped cordis default cannot start a session
  immediately if any preset they also use contains tool-cordis.
• The web UI silently absorbs the failure, so the bug looks like "the New
  Session button is broken" rather than a preset configuration issue.
• Workaround: change agent-presets.default to standard in
  ~/.dsh/settings.yaml. The cordis preset itself remains unreachable
  for the process lifetime.

[Electricitysheep]

tool-cordis 的 inspect-provider 注册破坏了默认 cordis 预设挂载——全新 dsh web 就踩到，说明是默认路径的问题（不是冷门配置）。

和第 3 章"预设挂载/依赖解析"的坑同类（#1415 的 Service 已注册也是单例冲突方向）。排查：确认 tool-cordis 与 cordis 预设的 provider 注册顺序。https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/03-profiles.md

[denial123789]

I confirmed the collision against the current source layout:

• tool-cordis/src/index.ts registers every hostInspectProviders(ctx) entry during plugin application.
• cordis-host-runner/src/inspect-registry.ts rejects an existing manifest ID.
• The shipped cordis preset includes tool-cordis.

That makes the reported process-lifetime behavior source-consistent.

For operators, the least invasive recovery is to switch the default to standard and restart the whole DSH process before creating another session. A restart matters because the registry is process-owned. Avoid patching register() to silently return success: unless disposer ownership or reference counting is also defined, one fiber can unregister a provider still used by another. Moving the built-in providers to host startup, or giving each preset isolated ownership, is the safer durable direction.

I added this as a tracked rc.6 boundary with the exact first evidence and workaround:
https://sandbaseai.github.io/deepseek-harness-handbook/field-status.html