Resume fails with "already registered" when a profile bundle and the session preset mount the same plugins

[LyraWang6688]

Version: DeepSeek Harness desktop 0.2.1-rc.2, macOS arm64 (nightly feed)

Symptom

Resuming an existing session fails with a RemoteError that lists core tools and prompt sections as duplicated:

RemoteError: persona (@deepseek-ai/dsh-persona): prompt section "deployment:persona-prefix" is already registered (for a per-agent override, register through that agent's agent.ctx instead)
tool-bash (@deepseek-ai/dsh-tool-bash): prompt section "tool:bash" is already registered ...
tool "todo_write" is already registered (for a per-agent variant, register through that agent's agent.ctx instead)
...
tool-subagent (@deepseek-ai/dsh-tool-subagent): tool-subagent: standing modelSelectionSettings requires a scoped preset Context
(gateway/internal)

• The affected session header is agentPreset: "cordis".
• New sessions start fine; only this session's resume fails.
• The session log itself is intact.

Environment

• Desktop profile with 15 bundles and a hand-maintained cordis.patch.yml.
• @deepseek-ai/dsh-subagent-codex appeared both in dsh.profile.bundles and as an installed dependency, plus patch-level entries for the same plugin family.
• Two subagent providers (dsh-subagent-codex, dsh-subagent-claude-code) are installed as dependencies.

What changed it

Removing @deepseek-ai/dsh-subagent-codex from dsh.profile.bundles (keeping the dependency installed and leaving the remaining patch config) made the resume work again — the duplicate mount disappeared.

Hypothesis / question

It looks like resuming a preset-backed session mounts the preset's plugin set into the same (Host) scope that already has those plugins registered from the profile bundles, so every NamedEntries registration throws instead of scoping into agent.ctx.

Questions:

1. Is there a supported way to declare a plugin exactly once when both a bundle and a session preset may provide it, without disabling the bundle entirely?
2. Should resume degrade gracefully (scope the preset mounts, or report a single clear error) instead of emitting a wall of duplicate-registration errors?
3. Any recommended ordering between dsh.profile.bundles and cordis.patch.yml entries to avoid double mounts?

Happy to attach a redacted profile patch/config if useful.

[argszero]

Thanks for the detailed report — the version, the profile shape and the "removing it from dsh.profile.bundles fixed it" step are what made this readable.

What that error actually is. It is not a wall of independent failures. It is one RemoteError('agent-preset/invalid') whose message is auditRows(tree).failed.join('\n') — the preset's own Loader tree, one line per unusable row, in the form <entryId> (<module>): <that row's own failure> (packages/preset/agent-preset-registry/src/mount.ts: mountPreset builds it, activate stores it as record.broken, retain rethrows it). A row that rejects with several causes renders them beneath the first as - member lines, which is why some of your lines carry no id (module): prefix. That is also why the list looks more uniform than the real failures are.

The discriminating fact is already in the text. The core error factories branch on scope === undefined:

• packages/core/system-prompt/src/index.ts:406-415 (sections, contexts, variables)
• packages/core/tools/src/index.ts:748 (tools)

They append (for a per-agent override, register through that agent's `agent.ctx` instead) only for the global layer, and say in this scope for a scoped one. Your persona and todo_write lines carry the per-agent hint, so those registrations hit the deployment (global) plane. That agrees with your hypothesis, and it is a useful thing to know for any future report of this shape: the parenthetical names the layer.

What a preset row is supposed to do. It is meant to register into its own scope and shadow the deployment. packages/preset/persona/src/index.ts says so in its own module docstring: mounted inside an agent preset it shadows the deployment persona for that one session; mounted globally it collides with the registry's own registration and fails loud. So a preset row reporting a global-layer rejection is not a missing scoping in the design — it is a row that registered on the plane the deployment already owns.

Your three questions.

1. Is there a supported way to declare a plugin exactly once when both a bundle and a preset may provide it? Not that I can find. I searched docs/ for such a rule and there is none. The supported shape is that the two lists are disjoint: a module belongs to the profile bundles (deployment plane) or to a preset's plugin list (scoped plane), never both. There is no "declare once" flag to set, which is why removing it from one of the two lists is the whole fix.

2. Should resume degrade gracefully? It already is one error rather than a crash, but the payload is unstructured prose: N rows joined by newlines under one code, so no consumer — UI or script — can tell the rows apart or act on one of them. Two changes are possible, and both are core-side: carry the rows as structured data beside the prose, and give the scope-isolation failure its own code instead of folding it into agent-preset/invalid.

3. Any recommended ordering between dsh.profile.bundles and cordis.patch.yml? Ordering does not help. The layer is chosen by the scope of the context a plugin registers from (ScopedLayers.effect in packages/core/scope/src/store.ts reads scopeOf(ctx)), not by mount order. Order only decides who wins a name, and the second registration throws either way.

One line in your paste is a second, different signal. Your last line is not a duplicate at all: tool-subagent: standing `modelSelectionSettings` requires a scoped preset Context is the compositionScope === undefined branch at packages/subagent/tool-subagent/src/index.ts:449. So two independent rows in the same tree report that they saw no scope at all. If that is really what happened, the more interesting question is not "my lists overlap" but "these rows registered without the scope they were supposed to have" — which would be a core question rather than a profile-layout one. Worth separating the two before doing more bundle surgery.

An instrument for the next round. I published a small plugin that takes that reading for you: @argszero/dsh-host-plane-registration-guard, source at https://github.com/argszero/dsh-host-plane-registration-guard. It reads agentPresets.list() and the Loader's entry tree — both public — and prints one line per failing row, naming the preset, the row, the registry name it claimed, the layer the rejection hit, and whether the same module is also mounted at the deployment plane:

preset cordis: persona (@deepseek-ai/dsh-persona) → section "deployment:persona-prefix" — this module is also mounted at the deployment plane; keep it in one of the two lists

Mount it with dsh plugin add @argszero/dsh-host-plane-registration-guard plus one dsh.profile.bundles entry (the package declares dsh.bundle.patch), or a single - insert: row in cordis.patch.yml. It is diagnosis only: it edits no composition, disables no row and writes no session, so mounting it changes nothing about how your profile behaves.

If it classifies your tool-subagent line as scope-required while persona comes out as a shared module, that confirms the split above and tells us which half to work on first. Paste the output together with the wall you get on resume and I will take the core side of it further.