Bug report: New Session silently fails when the default agent preset no longer exists

[skystar567]

Summary

When the configured default agent preset no longer exists, every "New Session" action in the Web UI fails silently: clicking "+" on any workspace (or the global New Session button) shows nothing at all. The only trace is new session failed: … agent-preset-not-found … in the browser console.

This bricked session creation for every workspace until the stale setting was repaired manually.

Environment

• dsh 0.1.0-rc.6 (installed globally from npm), Node 24, Web profile (dsh web), Chromium, zh-CN UI
• ~/.dsh/settings.yaml contained agent-presets.default: anchored-standard while the preset roster only supplied standard, code, minimal, cordis, router-standard

Steps to reproduce

1. Start dsh web and open the UI.
2. In Settings → Agent presets, set the default to some preset (e.g. foo).
3. Delete that preset from the filesystem directly, not via the UI — e.g. remove its directory under ~/.dsh/.agent-presets/, or uninstall the plugin that supplied it.
4. In the sidebar, click the "+" (New Session) button on any workspace.

Expected

A New Session row appears under the workspace, or at least a visible error explaining the refusal.

Actual

Nothing happens in the UI. The click looks dead. Console shows:

new session failed: SessionCreateError: session create failed:
agent-preset-not-found: agent-presets: preset "foo" not found
(available: standard, code, minimal, cordis, router-standard)

Every new-session path is affected the same way: the per-workspace "+" button, the global New Session button, and the startup initial-workspace selection.

Root cause

1. AgentPresets.defaultId resolves to the stale settings value, and resolve() deliberately throws UnknownPresetError when the roster lacks it (the "default may name a preset authored later" design). So the Host correctly refuses session.create.
2. The client's WorkspaceRuntime.startSession (packages/client/runtime/src/client/workspaces/service.ts) catches that refusal with only console.warn('new session failed:', …) — no observable state, no UI surface. That is what makes the click look dead.
3. The inconsistency makes it worse: agentPreset.list marks no preset as default in this state, so the settings row and the new-session chip fall back to displaying the first roster preset (standard), while the Host still resolves the stale default and refuses. The UI shows "standard" but creates nothing.

Notes on the trigger

The stale default arose by deleting a preset outside the managed flow (from the command line; the preset originally came from a GitHub-installed plugin). That is an expected, real-world state — AgentPresets.remove() already clears a user default on managed delete, and the code comments explicitly anticipate presets being "deleted from disk outside remove". So the framework anticipates this state but then fails invisibly.

Suggested fix (already implemented in a local checkout, happy to PR)

• Publish the New Session failure on the workspace list state (newSessionError on WorkspaceListState in dsh-client-runtime), cleared by the next attempt or an explicit dismiss.
• Render a dismissible error banner (the Host's message verbatim) in the sidebar workspace browser (dsh-client-ui-workspace), so a refused click is never silent.
• Worth discussing separately: whether a stale default (no explicit preset named by the request) should degrade to a fallback preset instead of refusing, and whether agentPreset.list should flag "default names a missing preset" so the settings UI can warn instead of pretending the first roster entry is the default.

Workaround

Clear or re-pick agent-presets.default in Settings → Agent presets (or edit ~/.dsh/settings.yaml).

[SOGERSEN]

Related report: #4115 — a generalized version of this failure mode. When any active/in-use agent preset fails to mount (e.g. a broken custom preset created via create-mode), every New Session click from an existing session silently fails with zero UI feedback (startSession() only does console.warn), and reinstalling DSH does not help either since the broken preset persists under ~/.dsh/.agent-presets/. The stale-default case described here is essentially one specific trigger of the same underlying gap: preset mount errors never reach the UI layer and there is no fallback to a working preset. Cross-linking for triage visibility.

[rafalePOP]

Confirmed on DSH Desktop 2.0.3 / Windows 11. This was the same stale-default condition described here, including the misleading fallback display.

I reproduced it with a newly created TEST profile containing only the official @deepseek-ai/dsh-base and @deepseek-ai/dsh-web-app bundles, with no community plugins. Desktop was using Compatibility mode, No Window Material, and the valid workspace-write permission preset.

The shared ~/.dsh/settings.yaml still contained:

agent-presets:
  default: minimal-windows

minimal-windows was not available in the clean profile, and the user preset directory was empty. However, Settings displayed Standard mode, exactly as described in this report. Clicking New Session silently did nothing.

An important UI detail: selecting Standard mode again did not repair the setting because the UI already considered Standard selected; the YAML value remained minimal-windows. I had to select another existing preset first (PTC mode, which wrote code) and then select Standard mode again. The setting was then correctly saved as:

agent-presets:
  default: standard

Immediately afterward, without restarting Desktop, the global New Session button worked: a new New Session row appeared in the sidebar and the blank-session preview became selected.

This also explains why the problem persisted in a plugin-free profile: the agent-preset default is shared across profiles, while the preset that originally supplied minimal-windows was not available in the clean profile.

No diagnostic archive is attached because it contains local paths and session/workspace identifiers. I can provide sanitized excerpts if useful.

[WindBruce]

Addendum: still 100% reproducible on 0.1.5-rc.1 (the settings-default path)

so is any deployment whose settings still name code as the default

That is exactly what I hit:

1. Leave a default in settings.yaml that the roster does not supply:

   agent-presets:
     default: code

2. dsh web

3. Click the + on any workspace row, or the global New Session button.

Nothing happens in the UI. The console shows:

new session failed: SessionCreateError: session create failed:
agent-preset/not-found: agent-presets: preset "code" not found
(available: standard, ptc, minimal, cordis)

Three details that may help triage

1. It is not workspace-related. I verified it in a freshly added workspace and in an existing workspace that already has several sessions — identical behaviour. The failure happens inside composeAgent, before any workspace attachment (attachSession), so "new workspaces are especially affected" is only an illusion.

2. Nothing is visible at the HTTP layer. POST /api/session/create returns 200; the error travels inside the RPC payload, so the network panel looks clean too. The only traces are the console and the source.

3. The stale value can be a pure orphan. I checked the persisted session headers on this machine (first line of each sessions/*/session.v3.jsonl.zstd, decompressed):

session-79be4830-…  agentPreset="standard"
session-d4bc75d0-…  agentPreset="standard"
session-f3e95de8-…  agentPreset="standard"
session-f86c61cd-…  agentPreset="standard"

So default: code does not correspond to any session actually in use — it is just a value left behind in settings across versions, yet it blocks every new session. That is also why a "fall back to a shipped preset" fix would be safe in this scenario: nothing actually depends on the stale value.

A note on where the gap ends (would like your view)

In 0.1.5-rc.1 I can see that @deepseek-ai/dsh-session-format-v2-to-v3/lib/index.js already contains a code → ptc mapping:

// :687  session header
...header.agentPreset === "code" ? { agentPreset: "ptc" } : {}

// :819  agent-preset/selected event
case "agent-preset/selected": return event.data["agentPreset"] === "code" ? { ... } : ...

So on the current release the session-data side appears to be covered. The configuration side still has no migration at all — I scanned the installed packages:

dsh-session-format-v0-to-v1   references settings.yaml: false
dsh-session-format-v1-to-v2   references settings.yaml: false
dsh-session-format-v2-to-v3   references settings.yaml: false
dsh-api-settings-controller   references settings.yaml: false
dsh-settings                  references settings.yaml: false

I am not sure whether that v2→v3 mapping covers every historical format path — for example a session that is already at v3, or one that came up through v0/v1 step by step. If you have a moment, I would be curious to know: if the coverage is incomplete, the resume failures in #4829 might come from those edge paths, whereas what I hit is purely the configuration-side gap and is unaffected by that mapping either way.

Workaround confirmed

Setting settings.yaml to ptc takes effect without a restart (the settings document is hot-reloaded) — I created a new session successfully on the same running process right after the edit. This matches the observation in the Desktop comment on #1839.

Thanks again for the diagnosis and the patch!

[jngonzales]

Independent confirmation on 0.1.5-rc.1 (Windows 11, npm global, dsh web, en UI), plus the origin of the stale value.

Symptom: every New Session path was dead — the global button, the per-workspace click, and the startup initial-workspace selection. Console showed only:

new session failed: SessionCreateError: session create failed:
agent-preset/not-found: agent-presets: preset "code" not found
(available: standard, ptc, minimal, cordis)

settings.yaml contained agent-presets: default: code. Setting it to standard fixed it on the running process with no restart, matching the hot-reload observations above.

Where this case differs from the existing reports: the stale value was neither hand-edited nor a deleted custom preset. code was a shipped preset id, and an official rename is what stranded it.

• config/agent-presets/code/preset.yml shipped in every pre-0.1.2 release inspected (dsh 0.0.1-rc.1, published 2026-08-10, through 0.1.1-rc.2, published 2026-08-21). It displayed as 代码模式, later PTC 模式.
• Commit 3ca9c7d (2026-08-27) renames that preset's directory and id to ptc; no preset named code exists from 0.1.2-alpha.2 onward.
• Nothing migrates the settings value. AgentPresets.defaultId returns settings.get().default ?? config.default, resolve() throws agent-preset/not-found, and the only settings write in the package is op: "unset" when the currently-default preset is deleted through the UI.
• The session side is already covered: dsh-session-format-v2-to-v3 rewrites agentPreset: "code" to "ptc" (lib/index.js:687 and :819-823). So recorded sessions resume fine while the configuration stays stranded — the two halves disagree.

Consequence: this is not an exotic state. Anyone who selected Code mode in the picker before 2026-08-27 and then upgraded has every new session refused, while Settings still shows a valid mode (the picker falls back to the first roster entry), and POST /api/session/create returns HTTP 200 with the error inside the RPC payload, so there is no visible trace at the network layer either.

Suggested minimal fix, reusing what the repository already does for sessions: apply the same code -> ptc mapping to the settings default at read time, or fall back to the shipped default with a warning, instead of refusing; and have Settings flag a default the roster does not supply rather than rendering the first entry as selected. Happy to attach a tested patch if it is useful.