Agent preset selection is silently lost when switching workspace on the new-session screen

[KYinCode]

Agent preset selection is silently lost when switching workspace on the new-session screen

Summary

On the new-session screen, picking a non-default agent preset and then switching the workspace before creating the session silently discards the pick: the session is created with the deployment default preset instead. The preset chip may keep showing the picked preset (state/display desynchronization), so the user sees "selected" while the session actually runs the default — there is no error anywhere.

Environment

• dsh 0.1.0-rc.6 (web profile)
• Browser: Chrome 151, driven via chrome-devtools-mcp 1.7.0 (CDP) for the reproduction
• A user-authored preset exists at ~/.dsh/.agent-presets/v4-mcp-test/ (one dsh-mcp-client row, serverName testp), so the preset picker has a non-default option

Steps to reproduce

1. Open the new-session screen (workspace picker + preset chip are side by side).
2. Click the preset chip (default "标准模式" / standard) and pick a non-default preset (e.g. v4-mcp-test). The chip label updates.
3. Click "选择工作区" (choose workspace) and switch to a different workspace.
4. Type a first message and send it (this creates/activates the session).
5. Inspect the created session's persisted header (session.jsonl.zstd first line) → "agentPreset":"standard", not the picked preset.

Control run with the reversed order works: switch workspace first, then pick the preset, then send → the session header records the picked preset.

Expected vs actual

Expected: the session is created with the preset picked on the new-session screen, regardless of the order of workspace switching.

Order of operations	Persisted agentPreset
switch workspace → pick preset → send	picked preset ✅
pick preset → switch workspace → send	default (standard) ❌

Network evidence (CDP request log during the failing sequence): agentPreset.list is called (roster re-reads), but agentPreset.select is never called — not on the pick, not on the workspace switch, not on session creation. The session-creating call session.prompt carries no preset field at all — the preset is expected to reach the session through the front-end staged state.

Evidence (inline)

Failing session — persisted header created by the "pick → switch workspace → send" sequence (event stream contains only this line; no agent-preset/selected event):

{"type":"session","version":0,"id":"session-47ffa312-c1cf-41a8-a598-751780f86c07","createdAt":1786724713886,"cwd":"F:\\Project\\DeepSeekHarness\\dsh-project-mcp-bridge","delegationDepth":0,"agentPreset":"standard"}

Control session — same user preset via the host default path (agent-presets.default), header records it:

{"type":"session","version":0,"id":"session-1354ac64-1aa7-4b21-b500-cde83d40f3f6","createdAt":1786723481633,"cwd":"F:\\Project\\DeepSeekHarness\\mcp-v4-test","delegationDepth":0,"agentPreset":"v4-mcp-test"}

Session-creating request during the failing sequence — no preset field; the only preset-related traffic was agentPreset.list, never agentPreset.select:

{"type":"client-request","rpcId":"baeec506-d26d-445e-81e7-04655650c191","method":"session.prompt","payload":{"sessionId":"session-47ffa312-c1cf-41a8-a598-751780f86c07","mode":"queue","content":[{"type":"text","text":"你好"}],"clientTimeZone":"Asia/Shanghai"}}

Likely cause (front-end, dsh-client-ui-agent-preset)

The new-session preset chip is driven by the seat controller, whose contract is "stage a pick for the NEXT session, apply it when a (blank) session becomes current" (see AgentPresetSeatController docs: "The new-session screen has no session, so a pick is staged rather than applied. It reaches a session when one becomes current and is still blank… The stage is forgotten once applied.").

The stage is consumed (or silently dropped) by the apply path:

async apply() {
    const staged = this.staged;
    const session = this.currentSession();
    if (staged === void 0 || session === void 0) return;
    if (!session.blank || session.agentPreset === staged) {
        this.staged = void 0;   // silently discarded, display NOT reverted
        return;
    }
    await this.api.agentPresets.select({ sessionId: session.id, agentPreset: staged });
}

Switching the workspace changes the current-session placeholder (each workspace has its own blank "new session"), which can fire the list-change applier against a placeholder judged unservable — the stage is cleared without a select call. Depending on the interleaving with load() (which re-reads the roster after the switch), the chip either reverts to the default or keeps showing the staged pick while the stage is already gone — hence the "selected but not applied" illusion and the intermittent display behavior observed during reproduction.

Impact

Users who pick a preset and then switch the workspace (a natural order — the two controls sit side by side) get a session running the default preset with zero feedback. The chip display can lie (still showing the picked preset), so the mismatch may go unnoticed until the session's behavior shows it.

Workarounds

• Pick the preset after switching the workspace (verified stable).
• Use settings → agent-presets default (agent-presets.default), resolved by the host at session creation and unaffected by the staged-state path.

[oliblue-evan]

Good repro — this looks like a client-side state/ordering issue rather than a persistence one. The preset picker and the workspace picker are independent transient UI states, and the session is created from whatever the preset state holds at send time; switching the workspace apparently resets that transient state while the chip keeps rendering the stale label (hence the display desync you observed).

Two directions worth trying, in increasing order of invasiveness:

1. Fix the ordering bug at the source of truth: persist the preset selection in the composer state that survives workspace switching (the same slot that keeps the picked workspace), so the session is always created from the last visible selection. The chip already renders from a store — the creator just reads a different, reset snapshot.
2. Short-term user workaround (if a fix takes a while): re-pick the preset after switching the workspace — your control run shows that order works.

If maintainers want a quick code-level hint: on the new-session screen, the "create session" handler should read the preset from the same reactive source the chip subscribes to, not from a separate one-shot state that workspace switching invalidates.