Renamed agent preset leaves a stale user default that breaks new-session creation

[linkerlin]

Summary

When a shipped agent preset is renamed (e.g. code → ptc in 3ca9c7d), a user who previously selected the old preset as their default keeps agent-presets.default: code in ~/.dsh/settings.yaml. From then on, every new-session creation that relies on the default fails with agent-preset/not-found, and in the Web UI the failure is only visible as repeated console.warn output.

Reproduction

1. On a build that still ships the code preset, select code as the default agent preset (writes agent-presets.default: code to $DSH_HOME/settings.yaml).
2. Update to a build where code was renamed to ptc (available roster: standard, ptc, minimal, cordis, ...).
3. Open the Web UI and start a new session.

Actual: SessionCreateError: session create failed: agent-preset/not-found: agent-presets: preset "code" not found (available: standard, ptc, minimal, cordis, liangshen) — repeated, because the workspace navigation watcher (packages/client/ui-workspace/src/client/navigation.ts) resets to waiting after each failure and retries. The user sees a silently broken "new session" button; only devtools shows the cause.

Expected: a stale default preset is migrated, cleared, or surfaced — never a hard failure loop.

Root cause

• Default resolution is settings?.get().default ?? config.default (packages/preset/agent-presets/src/index.ts, defaultId). The user-layer value is trusted verbatim; resolve then reports the missing id.
• The deletion path already clears a user default that points at a deleted preset (agent-presets/src/index.ts, the mutate call unsetting ["default"] after delete), but a rename in the shipped roster is not a deletion through any code path — nothing clears or migrates the stale value.
• Session creation without an explicit pick (ClientSessions.create({ workspaceId })) has no fallback when the default fails to resolve.

Suggested directions (pick one or combine)

1. At session-create time, fall back to config.default (or the first roster entry) when the user-layer default is absent from the roster, and log/emit a visible notice instead of failing.
2. Validate the user-layer default on load and auto-clear it when the id is not in the roster, mirroring the delete-path behavior.
3. Ship a settings migration for known renames (code → ptc).

Option 1 or 2 fixes the general case; option 3 only patches this specific rename.

Workaround

Edit $DSH_HOME/settings.yaml and change agent-presets.default to an existing preset id (or remove the key), or re-select the default preset in the settings UI.

[Fantasymax]

同款情况，补充一个数据点：

• 0.1.2-rc.1 → 0.1.3-alpha.2 升级后，settings.yaml 里 agent-presets.default 还停留在旧名 code，web 端点「新建会话」完全无反应。
• 服务端其实返回了明确错误（/api/session/create → agent-preset/not-found，available: standard, ptc, minimal, cordis, liangshen），但前端把错误吞掉了——按钮表现就是"点了没反应"，也没有任何提示，用户很难自助定位到预设改名。
• 把 default 改成 standard 并重启后恢复。

两个可改进点：① 升级时迁移/自动映射被改名的预设默认值；② RPC 失败时前端至少给个 toast，而不是静默无反应。

[argszero]

Confirmed against the source — this is a real, reproducible bug with a clean mechanism, and you've nailed both halves of it.

Server-side (the actual failure). agent-preset/not-found is raised from resolve(id?) in packages/preset/agent-presets/src/index.ts:344-350:

const wanted = id ?? this.defaultId
const presets = await this.list()
const found = presets.find(preset => preset.id === wanted)
if (found === undefined) {
  const available = presets.map(preset => preset.id)
  throw new RemoteError('agent-preset/not-found', `preset "${wanted}" not found (available: ...)`, {...})
}

defaultId is a getter that reads through from plugin config every call — it does not revalidate against the current preset set. So after the code → ptc rename (3ca9c7d489), a user whose settings.yaml still carries agent-presets.default: code resolves wanted = "code", finds nothing in list(), and throws. The error payload carries available — exactly the list you saw (standard, ptc, minimal, ...). This is a static-but-stale-default bug: nothing migrates the persisted default on rename, and nothing treats a stale default as "fall back to the new equivalent."

Client-side (the silent swallow). Fantasymax's datapoint is the aggravating half: /api/session/create returns the RemoteError, but the frontend drops it and the button just appears dead with no feedback. A user cannot even discover that the preset was renamed. That's a separate UX bug — the error reaches the wire but never surfaces.

Fix shape (two sides, both worth doing):

1. Server — stale-default recovery. resolve() should distinguish "no default configured" from "default configured but no longer available." When defaultId points at a preset that no longer resolves, instead of throwing a hard not-found that blocks every session creation, it should either (a) fall back to the first available preset with a warning, or (b) throw a more specific error with a clear migration hint ("your default code was renamed to ptc"). Option (b) is better for the missing-migration case but doesn't unblock the user; the truly robust fix is (a) + a one-time settings migration when a preset rename ships. Since renames are a code-level event and the default is an id, a principled approach is: on resolve-stale, warn + fall back to the replacement id if a rename mapping is known, else warn + first available.

2. Client — surface the error. The new-session button should surface a RemoteError from create (a toast/log) rather than swallowing it. Even a minimal "preset not found — update your default" affordance would convert a dead button into a self-serviceable state.

This is a compact, well-contained bug — the server half is genuinely fixable in resolve()/defaultId, and I'd be glad to help draft the fallback predicate or the rename-mapping if you want to take a stab at it. It also connects to the remove-without-signal family (#5859): a rename that breaks persisted defaults is a config surface of the same "change shipped without migrating consumers" root cause.