Session resume fails: Host Cordis inspect provider "Service" is already registered (process-singleton registry collides between preset mounts)

[MasterToycode]

Describe the bug

Resuming a session whose agent preset includes the Cordis toolset fails with:

resume failed for session "session-…": Error: 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

Once this happens the conversation can no longer be reopened at all — every prompt attempt fails the same way. The session's stored data is intact (it is a mount-time failure only, not data corruption).

Environment

• DSH 0.1.0-rc.6, web profile, Windows
• Reproduced while running two sessions in one host process: one on the shipped cordis preset, one on a locally authored preset that also mounts a tool-cordis row

Root cause (from source)

1. CordisInspectRegistryService is a process-global singleton created by DynamicCordisRunnerService on the host plane (new CordisInspectRegistryService(ctx), service key cordisInspect, in @deepseek-ai/dsh-cordis-host-runner). Its register() throws Host Cordis inspect provider "<id>" is already registered when the provider id already exists in its Map.
2. @deepseek-ai/dsh-tool-cordis registers the first-party Host inspect providers (Service, Event, Builtin, Tool) unconditionally in apply():

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

3. Because the registry is a process singleton, the vanilla package can be mounted only once per process. Two sessions whose presets both carry a tool-cordis row (e.g. the shipped cordis preset and any locally authored preset that copies it) collide: whichever mounts second throws, which fails the whole preset mount, which fails the session resume. The failure is order-dependent: the first mount wins and holds the ids until its fiber is disposed.

In my case it appeared in two shapes. First, a session on the shipped cordis preset that was torn down abnormally (a command error interrupted its last turn) left its four provider ids behind in the process-global registry, so every subsequent resume of that same session collided with its own leftover registration. Second, after a host restart, resuming the same session while a locally authored preset (a patched copy of dsh-tool-cordis) was already live failed identically, because the vanilla package threw on Service. Either way the conversation stays unrecoverable until the holder goes away or the process restarts.

Workaround I use locally

I patched a copy of dsh-tool-cordis whose registration loop catches the duplicate error and skips it (the providers are identical, so sharing one registration is correct):

for (const provider of hostInspectProviders(ctx)) ctx.effect(() => {
  try {
    return ctx.cordisInspect.register(provider);
  } catch (error) {
    if (error instanceof Error && error.message.includes(`inspect provider "${provider.manifest.id}" is already registered`)) return () => {};
    throw error;
  }
}, `tool-cordis: inspect ${provider.manifest.id}`);

This makes the patched preset tolerant when it mounts second, but the vanilla cordis preset still fails when it mounts after another tool-cordis instance — the collision is only fixed in one direction.

Suggested fixes

1. Make CordisInspectRegistryService.register() idempotent for duplicate ids (reference-counted, or replace-and-return-disposer).
2. Or register the first-party Host inspect providers once on the host plane (they are static catalogs plus live Tool scope — nothing about them is per-session) instead of from every preset mount.
3. Or scope the registry per agent/session.
4. Regardless of the fix, improve the failure surface: today the error is an opaque "resume failed" with no hint that another live session holds the provider, and the session stays stuck until that holder goes away.

Although I’m still a university student, if any of the experts or maintainers could tell me exactly where to submit it, I’d like to submit a PR.
Wishing you all the best! Thank you!

[moonquake2004]

Great write-up — the source-level analysis is clear and the repro is well scoped. This is the sibling of a bug I filed earlier today (#1404): the same plugin being mounted twice in one host process isn't handled idempotently anywhere in the stack.

• dsh plugin add promotes pre-existing bundle-declaring deps into the bundle stack and breaks the next boot with "duplicate loader entry id" #1404: a profile's user patch (cordis.patch.yml) and a promoted bundle layer both insert the same entry id → the loader's EntryGroup.update throws duplicate loader entry id at boot.
• Session resume fails: Host Cordis inspect provider "Service" is already registered (process-singleton registry collides between preset mounts) #1415 (this one): two presets in one process both mount dsh-tool-cordis → the process-singleton CordisInspectRegistryService.register() throws already registered on session resume.

Same theme, different layer — yours is the runtime/service layer, mine is the composition layer. If a maintainer picks up either one, the other is worth checking for the same class of fix (idempotent registration / dedupe vs. preventing the duplicate mount in the first place).

On your workaround: the catch-and-skip patch is reasonable, and your fix suggestions look right — I'd personally lean toward making register() idempotent (reference-counted or replace-and-return-disposer), since "first-party providers are static catalogs + live Tool scope" means per-session registration is redundant anyway. The failure-surface improvement (#4) is also very valuable — "already registered" with no pointer to the holder made this much harder to diagnose.

About where to submit the PR: heads-up that per the repo's CONTRIBUTING.md the project currently does not accept external pull requests, and GitHub Issues are disabled — Discussions (this post) is the supported channel, and the team says they monitor and consider them when allocating resources. Keeping your patch ready in a fork/gist and linking it here is probably the most useful next step until that changes.

Really solid report — thanks for writing it up so thoroughly.

[MasterToycode]

Thanks for the detailed reply — and for flagging #1404 as the sibling bug. Same class of issue indeed: the stack assumes each plugin/entry/provider is mounted once per process and doesn't dedupe when the same thing is mounted twice — composition layer in #1404, runtime/service layer here.

Good to know about CONTRIBUTING.md — I'll keep the patch in a gist rather than a PR. It's here: https://gist.github.com/MasterToycode/f44a5be6687c7dd916d04adf9b7b8d82 (based on 0.1.0-rc.6; diff vs. the shipped @deepseek-ai/dsh-tool-cordis is only the inspect-provider registration loop, everything else byte-identical).

On direction: I agree register() being idempotent (reference-counted, or replace-and-return-disposer) is the cleanest — the first-party providers are static catalogs plus live Tool scope, so per-session registration is redundant anyway; "register once on the host plane" would remove that redundancy entirely. Happy to help validate whichever direction the team picks — I can test a fix locally or provide more logs/repro steps.

Thanks again for the quick response!

[MasterToycode]

Follow-up: recovery verified

Confirmed the recovery path works: closing the live session on the locally authored preset (normal teardown) released the four provider ids — the effect disposers run on clean session teardown — and the stuck cordis-preset session then resumed successfully without a process restart.

This also confirms the leak only happens on abnormal teardown (e.g. a turn interrupted by a command error), which is exactly the "leftover registration" shape described above: clean close → ids freed; abnormal end → ids stay until the process restarts.

One more data point: while the holder was live I also tried hot-patching the singleton's register() from a dynamic Cordis plugin — the dynamic-plugin sandbox silently blocks assignment to host services, so there is no in-process workaround. Restart, or close-and-reopen in the right order (mount the cordis-preset session before any other tool-cordis session), is the only recovery until the stack is fixed.

Operational rule for anyone hitting this: in one host process, open the cordis-preset session first; a locally authored preset with a patched copy can be opened afterwards (it skips duplicates), but the vanilla cordis preset cannot mount second.

[moonquake2004]

Independent verification — I reproduced the core mechanism against the real packages (@deepseek-ai/cordis + @deepseek-ai/dsh-cordis-host-runner, 0.1.0-rc.6) with a plugin shaped exactly like dsh-tool-cordis's apply (ctx.effect(() => ctx.cordisInspect.register(provider), ...) for the 4 providers). All 7 checks passed:

1. First mount registers all 4 providers (Service/Event/Builtin/Tool) ✅
2. Second mount in the same process throws verbatim: Host Cordis inspect provider "Service" is already registered ✅
3. Clean teardown (fiber.dispose()) runs the collected disposers → all 4 ids freed ✅
4. Re-mount after teardown succeeds (recovery without restart confirmed) ✅
5. No dispose → ids remain (leak state) ✅
6. In leak state, another mount throws the same error ✅
7. Cleanup frees everything ✅

The disposer wiring is exactly as you described: ctx.effect(fn) executes fn immediately at mount and collects its return value as the teardown disposer (cordis _execute), and register() returns an idempotent disposer that deletes only its own registration (dsh-cordis-host-runner register()).

One small nuance on your sandbox note: the block isn't quite "silent" — the sandbox ctx's set trap throws sandbox ctx is read-only; cannot assign "<prop>" and reports the guard failure to the owning agent. If your hot-patch attempt was wrapped in a try/catch (or the error landed somewhere you didn't surface), that would explain the silence. The practical conclusion is unchanged — dynamic plugins get a read-only façade with no writable handle to host services, so there's no in-process workaround.

The only thing I couldn't reproduce end-to-end is the full session-resume failure itself (needs the real preset/session machinery), but the mechanism chain is fully confirmed, so the outcome follows. Thanks again for the thorough write-up — this one is now solidly documented.

[MasterToycode]

---

Thanks for the independent verification — the 7-check matrix nails the mechanism, and the "idempotent disposer that only removes its own registration" detail matches what I read in register()'s source (the disposer compares the stored entry by identity before deleting).

Two notes from our side:

1. Sandbox behavior: on our path the hot-patch plugin reported "running" with no diagnostics and the duplicate-registration probe still threw, so the assignment was a silent no-op for us (consistent with a non-strict proxy set trap, possibly contained before surfacing) rather than the read-only guard failure you observed. Either way the conclusion is identical: dynamic plugins hold no writable handle to host services, so there is no in-process workaround.

2. End-to-end reproduction of the session-resume failure (the piece you couldn't reproduce): with the patched local preset live in the host process, resuming a real cordis-preset session fails with exactly:

   resume failed for session "session-ba9a4666-9aa3-4925-a48c-f9c8a8d14ef7": Error: 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
   (C:/Users/Administrator/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/config/agent-presets/cordis/agent.cordis.yml)
   

   And after closing the live preset session (normal teardown → disposers run → ids released), the same session resumes successfully without a restart.

Thanks again for taking the time to verify this.

[tdlxgpp]

Additional reproduction from a second environment (Windows, web profile)

Same root cause, one more trigger path worth adding to the report:

Trigger: editing a preset then creating a new session in the same host process.
We run the shipped cordis-based preset (cordis-zcode). After editing our preset
composition and trying to create a new session in the same running dsh web
process, creation failed at preset mount with the exact same error:

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

Evidence that the failure is at preset mount, not session storage:

1. sessions.create() (bare, no preset) succeeded — the session log row was created.
2. The mount step (standingKeyFor → compose → apply tool-cordis) threw on the
   second registration of provider id Service (CordisInspectRegistryService.register,
   process-global Map, throws on duplicate id).
3. The stale session was a 319-byte empty log created before any of our plugin
   work that evening — proving the collision existed as soon as the first
   cordis-based session had mounted in that process, independent of our edits.
   The "edit preset" was a red herring; the timing coincided.

Impact on the operator: once a process hosts one cordis-based session, every
further cordis-based session create/resume in that process fails, and the only
recoveries are (a) restart the host process, or (b) create the second session with a
non-cordis preset. Sessions are NOT corrupted — mount-time failure only.

Additional suggestion on the fix, on top of the ones already listed:
even a minimal change (catch the duplicate-id error in the tool-cordis registration
loop and treat it as "already registered by a peer — reuse") would remove the
user-facing breakage, since the four first-party providers are static catalogs
whose registrations are interchangeable. We verified the collision is purely
order-dependent: the first mount wins and holds the ids.

Environment: DSH 0.1.0-rc.6 (latest on npm as of 2026-08-14), Windows 11, web profile,
two workspaces (C:\Users\Public\harness and a user-profile workspace) in one host process.

Happy to provide logs / session excerpts on request. Thanks for the thorough write-up!

---

Local patch we applied (works in production, verified)

We patched the registry itself so duplicate-id registration is idempotent instead
of throwing. This fixes every preset at once (no per-preset workaround needed), and
keeps the first registration as the live one.

File: @deepseek-ai/dsh-cordis-host-runner/lib/index.js (the bundle entry — the
class is inlined there; there is also a standalone copy at
lib/types/inspect-registry.js that deep-imports may use, patch both).

Before (upstream):

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`);
    const stored = { ...registration, manifest };
    this.providers.set(manifest.id, stored);
    return () => {
        if (this.providers.get(manifest.id) === stored)
            this.providers.delete(manifest.id);
    };
}

After (local patch, marked LOCAL PATCH in source for upgrade visibility):

register(registration) {
    const manifest = validateManifest(registration.manifest);
    if (this.providers.has(manifest.id)) {
        // Idempotent: a second cordis-based session mounting the same static
        // first-party providers reuses the existing registration.
        console.warn(`[dsh-local-patch] Host Cordis inspect provider "${manifest.id}" is already registered; reusing existing registration (idempotent)`);
        return () => { };
    }
    const stored = { ...registration, manifest };
    this.providers.set(manifest.id, stored);
    return () => {
        if (this.providers.get(manifest.id) === stored)
            this.providers.delete(manifest.id);
    };
}

Why it is safe: the four first-party providers (Service, Event, Builtin,
Tool) are static catalogs plus live Tool scope resolved per query via the
requesting agent (ctx.tools.schemas(context.agent)), so registrations from
different sessions are interchangeable; sharing one is correct. The disposer is a
no-op for the duplicate so the first holder keeps ownership until its fber dies.

Verification: after restarting the host process, a duplicate register() no
longer throws (returns a no-op disposer and logs the warn line), and a second
cordis-preset session mounts successfully in the same process. Note: the patch
lives in node_modules — an npm update of dsh overwrites it; we re-apply after
upgrades and flagged it in our local notes.

Note on Windows installs: ~/.dsh/profiles/node_modules/@deepseek-ai/* are
junctions to the global npm install directory, so patch the global copy (the
junction resolves to it); don't edit the junction itself.

[MasterToycode]

Thanks for the additional data point — same root cause, and it adds a valuable trigger path: a second session on the same preset (no locally authored preset required) is enough, because every session mount registers the four first-party inspect providers and the registry is process-global.

One question to help isolate the trigger: did the failure also reproduce with a new session alone (no preset edit), or only after the edit? If the edit itself re-composed the standing mount while the old fiber's ids were still held, that would be a distinct trigger worth separating.

Either way the minimal repro is now: open session A (default preset) → open session B (same preset) → B fails at mount.

[tdlxgpp]

To answer your question directly: no preset edit is required — the edit was a red herring. The failure reproduces with a new session alone, as long as a cordis-based session has already mounted in the same host process.

Evidence from our side: the stale failing session was a 319-byte empty log created before any of our preset edits that evening, yet it still collided at mount — so the collision exists from the moment the first cordis-based session mounts, independent of any editing. Your minimal repro (open session A → open session B → B fails at mount) matches exactly what we observed.

FWIW our idempotent-register patch also covers this path, since it's the same duplicate-id throw.

[MasterToycode]

Thanks — that's a useful simplification: no preset edit needed, the trigger is purely "a second tool-cordis mount in the same host process".

It also reframes the two "stuck" shapes: (a) while another tool-cordis session stays alive, a new one simply cannot mount (the ordering rule is the only workaround); (b) after abnormal teardown, leftover ids keep colliding even with no other live session — that's the leak, fixed only by restart or by normal close of the holder. Both reduce to the same missing idempotency in register().

I'll fold "no preset edit required" into the report's repro section. And good to know your idempotent-register patch covers this exact path.Thanks.

[Electricitysheep]

Session resume 撞上 Service 已注册——预设挂载的进程单例冲突（Cordis toolset 被重复注册）。

和第 3 章"依赖/挂载解析"同类：多预设叠加时单例服务冲突。排查思路（哪个 preset 重复挂了 Cordis toolset）见第 3 章：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/03-profiles.md

[MasterToycode]

Thanks for the additional information! The mechanism aligns with the analysis in our post: every time a preset is mounted, tool-cordis repeatedly registers four provider IDs (Service/Event/Builtin/Tool) in the process singleton’s Host inspect registry. The second mount point immediately throws an already registered error, causing the entire preset mount to fail → session resume failure. "Identifying which preset has duplicated the Cordis toolset" is indeed the fastest troubleshooting approach.

Here’s an additional conclusion we’ve verified: Normally closing a session releases these IDs (the disposer takes effect), but they persist only in the event of an abnormal exit, causing subsequent resumes to repeatedly fail. The workaround is to restart the process or open and close sessions in the correct order (starting with the session using the Cordis preset first). This post contains a complete reproduction and a patch (Gist link). Chapter 3 mainly covers pitfalls related to profile mounting and dependency resolution; if convenient, this singleton conflict case could also be added to Section 3.5.

[moonquake2004]

Thanks for the second-environment reproduction — the new trigger path (edit preset → create session) is a useful extension: it shows the collision fires on any remount of tool-cordis in the same process, not just session resume — your 319-byte empty-log evidence pins it to the mount step itself, independent of any session data. That broadens the fix scope: an idempotent register() (or host-plane-once registration) covers resume, create-after-edit, and any other remount path in one change. (Our independent verification in the earlier comment already covered the mechanism; this adds trigger-path breadth.)

[MasterToycode]

Thanks for the confirmation — glad the second-environment repro was useful. Agreed on the fix scope: an idempotent register() (reference-counted, or replace-and-return-disposer) — or a host-plane-once registration — would cover resume, create-after-edit, and every other remount path in one change.

My catch-and-skip patch is only a one-direction workaround until then (the vanilla preset still fails when it mounts second). If it helps, I can update the gist to an idempotent-disposer version — one that keeps a per-provider disposer stack and only removes its own registration on teardown, matching the direction you suggested — as a concrete reference for whoever picks this up.

Also happy to test an upstream fix against our environment (two presets both carrying tool-cordis, Windows web profile) as soon as one lands.