tool-cordis registers Host inspect providers globally → any second mount of a preset containing it fails (New Session appears to do nothing)

[codeami]

Environment

• @deepseek-ai/dsh 0.1.1-rc.2, web profile, macOS (darwin-x64)
• Default agent preset: cordis (shipped) at the time of the failure
• Running session: a custom copy of the cordis preset
  (${DSH_HOME}/.agent-presets/<id>/agent.cordis.yml)

Summary

With one session already running a preset that contains the tool-cordis row,
creating a second session with any preset that also contains it fails:

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

The client swallows the failure — connectedWorkspace() rejects and the client
only does console.warn("new session failed:", reason)
(dsh-client-runtime/lib/client.js), so clicking "New Session" appears to do
nothing at all.

Reproduction

1. Start dsh web.
2. Open/create a session whose preset contains the tool-cordis row
   (shipped cordis = "Creator mode", or any custom copy of it).
3. With that session still open, click New Session (default preset also
   cordis).
4. Nothing happens in the UI. In the browser console:

new session failed: SessionCreateError: session create failed:
agent-preset-invalid: 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

Expected

Two sessions can run creator-mode presets concurrently (the inspect providers
are read-only runtime introspection — nothing about them is session-specific).

Actual

The second mount always fails. Consequence: one creator-mode session per
dsh web process, and after a host restart whichever creator session mounts
first wins; the other can never open.

Analysis

The row lives in the preset plane (agent.cordis.yml), so it is re-applied
per session, but the inspect-provider registration it performs lands on the
host plane, which is process-global. First mount claims the names
(Service, Event, Builtin, Tool, …); every later mount conflicts and
fails the whole preset — which fails session creation.

Suggested fixes (any of)

1. Make the inspect-provider registration idempotent or scope-aware — e.g.
   key registrations by owning agent/session, or treat an identical
   re-registration from the same package as a no-op. This is the real fix and
   allows N creator sessions.
2. Surface session-create failures in the UI. A failed New Session should
   show the error, not only a console.warn. Today the user has no signal at
   all.
3. Optionally, ship a preset-level switch so a custom preset can omit
   tool-cordis without hand-editing the composition (helps as a stopgap).

Workaround (for anyone hitting this)

Set the default preset to one without the row so new sessions can be
created:

# ${DSH_HOME}/settings.yaml
agent-presets:
  default: standard   # standard | code | minimal — all have no tool-cordis row

Creator mode remains usable, but only for one session at a time.

[PerryLink]

Your plane analysis is right and the throw is where you point. One fact changes both the repro and the conclusion: standing preset mounts are shared per preset id, so two sessions on the same preset never collide. What collides is two different preset ids that each carry the row — which is what your environment section describes (a user copy plus the shipped cordis), even though your repro steps read as if both sessions use the shipped cordis.

The registration

packages/extensions/tool-cordis/src/index.ts:24-26 registers one provider per name, inside an effect:

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

The ids come from packages/extensions/tool-cordis/src/providers.ts:28-63 — Service, Event, Builtin, and Tool.

So the registration is not leaked, and there is an unregister path: ctx.effect ties the disposer to the calling fiber, and CordisInspectRegistryService.register() returns an idempotent disposer (packages/extensions/cordis-host-runner/src/inspect-registry.ts:61-69). What is global is the store it registers into, and how long its holder lives:

• inspect-registry.ts:45-46 — one providers Map on the service instance.
• inspect-registry.ts:51-54 — the constructor doc: "Register the process-global Host registry"; super(ctx, 'cordisInspect').
• packages/extensions/cordis-host-runner/src/index.ts:143 — constructed once, with the host composition's context, inside DynamicCordisRunnerService.
• inspect-registry.ts:63 — the duplicate check, and the exact message you saw.

The holder is the first preset's standing mount, and those are process-lifetime by design: "standing mounts are one per preset and live until whole-tree teardown" (packages/preset/agent-presets/src/mount.ts:383-385), and "standing mounts are shared and permanent" (packages/preset/agent-presets/src/index.ts:664-665). Your "process-global in effect" reading is exactly right.

What a second mount does

The row's apply throws, the mount rejects with agent-preset/invalid (mount.ts:406-423, id at 417-422 and the message assembled at 341-357 — that is where your failed to apply loader entry … frame comes through), the failed standing entry is deleted and its scope disposed (index.ts:816-820), and because mount() runs in the agent factory's setup, the rejection rolls the whole agent creation back: "a broken preset never yields a half-composed session" (index.ts:430-443). Hence a failed session create rather than a degraded one.

When it collides, and when it does not

mount() resolves the preset and then calls ensureStanding() (index.ts:443-456), which is keyed by preset.id and single-flights per id (index.ts:776-797); an already-standing generation is reused while its composition stamp is unchanged (index.ts:785-786). Therefore:

• Same preset id, two sessions → one mount, one registration, no conflict.
• Two different ids that both carry the row → two mounts, second one fails. The shipped cordis is the only shipped composition containing the row (packages/preset/agent-presets/presets/cordis/agent.cordis.yml:260-261), so this means cordis plus a copy, or two copies — your setup.
• Same id after the composition file changes → ensureStanding compares a stamp, and on a change drops the standing entry and mounts a new generation while the previous one is still alive (index.ts:786-796, with reclaiming it still an open TODO at 787-792). That is a second registration of the same provider ids from the same package, so it should hit the same wall. I read this from the code; I did not reproduce it.

Two consequences for the write-up: the collision needs two preset ids, not two sessions, so "one creator-mode session per dsh web process" is better stated as "one row-carrying preset id at a time"; and the repro should pin session 1 to a copy rather than offering the shipped cordis as an equivalent, or it will not fail.

The swallowed failure

Correct, and the source line is packages/client/ui-workspace/src/client/navigation.ts:193-195 — void this.openWorkspace(target).catch((reason: unknown) => { console.warn('new session failed:', reason) }). (The path you cite is the built artifact.) That is also covered by a spec asserting exactly the warning, packages/client/ui-workspace/tests/workspaces-service.client.spec.ts:443.

Fix angle

The repo already solves this exact "the same package mounted in N presets registers N times" shape by counting registrants instead of rejecting the second: packages/session/session-projection/src/index.ts:273-291 — a second registration of a key at the same stateVersion just increments refs (line 282) and the key survives until the last disposer (line 289). Also relevant: mountPreset already polices rows that publish process-global services (mount.ts:398-404), but registering a provider into a host service is invisible to that check — which is why a row like this is legal in the preset plane at all.

Not verified: I did not run a host, so the runtime ordering (which mount wins after a restart, and the second-registration failure itself) is read from the code rather than observed. I did not reproduce your failure, and I have not run the stamp-change path.