[Bug Report] Switching default agent preset to cordis while a standard session runs wedges new-session creation (tool pwsh already registered, dsh 0.1.1-rc.2)

[Saretheya]

Environment

• dsh 0.1.1-rc.2, npm global install, Windows x64
• web profile, shipped preset files only (no custom presets involved)

Reproduction

1. Start dsh web and open a session on the shipped standard preset (it stays running).
2. Switch the default agent preset to the shipped cordis preset (e.g. agent-presets.default: cordis in the settings file, or via the Agent Preset section of the settings page, which says it applies to new sessions).
3. In the web UI, click "New session": nothing visibly happens. The button does call POST /api/session.create, but the server answers HTTP 200 with ok: false:
   • code: agent-preset-invalid
   • message: agent-presets: preset "cordis" failed to mount: loader entries failed to apply → failed to apply loader entry tool-pwsh (@deepseek-ai/dsh-tool-pwsh): tool "pwsh" is already registered (for a per-agent variant, register through that agent's agent.ctx instead)
4. Switching the default back to standard restores session creation immediately (no process restart needed).

Root cause

• Both shipped compositions config/agent-presets/standard/agent.cordis.yml and config/agent-presets/cordis/agent.cordis.yml contain a tool-pwsh row that registers into the host-scale global tools registry with no realm isolation (the files' own comments state these rows "register into the host tools registry and provide nothing, so they need no realm").
• Presets mount once per preset in one process. With standard already mounted, mounting cordis re-registers tool-pwsh in the global layer; dsh-tools rejects the duplicate name and the whole preset mount fails.

Relation to earlier reports

• Same family as Session resume fails: Host Cordis inspect provider "Service" is already registered (process-singleton registry collides between preset mounts) #1415 / [Bug Report] 两个 agent preset 同时包含 tool-cordis 时会话 resume 失败：Host Cordis inspect provider "Service" is already registered #2775 / Two preset-mounting bugs in 0.1.1-rc.2 (symlinked preset dirs skipped in discovery; duplicate inspect provider registration) — with patches #4542 (duplicate registrations when two presets compose the same rows), but those concern tool-cordis's Host inspect providers, which appear fixed. This report is the same class of defect on a different collision point — the host-scale tools registry (tool-pwsh) — so the earlier fix does not cover it.
• The generic gap: preset rows that write host-plane global registries have no dedup/idempotence, so switching the default preset to something other than the already-mounted one can wedge new-session creation with no visible UI error.

Suggested fix

• Make duplicate tool registration in the global layer idempotent (skip an identical already-registered row), or scope preset shell/tool rows per-preset realm, or add a pre-mount dedup audit for preset rows targeting host registries with an actionable error instead of agent-preset-invalid.

[liyangbing]

The rc.2 diagnosis is consistent with the pinned source: both shipped presets mount an unisolated tool-pwsh, and the older root registry rejects the second pwsh name. Switching back to the already-mounted standard preset is therefore the least-invasive immediate recovery; removing tool-pwsh from a shipped composition would silently remove the Windows shell capability and be overwritten by upgrades.

There is an important current-source boundary: at 0.1.2-alpha.1 (cd5ef814), the two presets still declare tool-pwsh, but the tool registry is now scope-layered. Each preset mounts under one standing scope, joined Agents inherit it, and tools.register() inserts into the calling layer. Sibling standard and cordis scopes may therefore own the same tool name, while a duplicate inside one scope still fails loudly.

That is structural source evidence, not a Windows E2E PASS for a mixed prerelease installation. I would verify one exact package graph with this sequence: keep standard Session A live and call pwsh; switch to cordis, create B and call pwsh; return to A and call again; dispose B; create standard C; then cold-restart and repeat. New Session success alone does not prove registration and disposal ownership.

I added the rc.2 recovery, alpha.1 scope boundary, source links, and execution/disposal matrix to the independent preset runbook: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/preset-generation-not-reclaimed.md#the-rc2-pwsh-collision-has-a-newer-scope-boundary