Bug report: changing the default agent preset does not apply when a workspace reuses an existing blank session

[sishuai33-commits]

Environment

• @deepseek-ai/dsh 0.1.0-rc.6, web profile (dsh web)

Steps to reproduce

1. In Settings → Agent presets, set the default preset to a custom preset (e.g. router-standard, then later minimal).
2. The current workspace already contains a blank session that was created earlier under a different preset (e.g. standard).
3. Click "New conversation".

Expected

The new conversation should run under the current default preset (agent-presets.default).

Actual

The workspace reuses the existing blank session, which keeps the preset it was originally created with. The session header shows the old preset (e.g. 标准模式), so the settings change appears to have no effect. This is reproducible with both custom and built-in presets.

Root cause (from reading the installed client source)

• workspaces.connectWorkspace (client runtime) first looks for any existing blank session in the workspace and returns it without switching its preset.
• agentPresets.default is only consulted when a session is truly newly created.
• The new-session hero chip also shows currentSession()?.agentPreset before falling back to the deployment default, so it can display the old blank session's preset too.

Suggested fix

When reusing a blank session, switch it to the current agentPresets.default first (the host already supports this for blank sessions via agentPreset.select / AgentPresets.recompose). Alternatively, the hero chip should prefer the deployment default over the current session's preset, and stage that default when a blank session becomes current.

Current local workaround

A small injected host plugin listens to agent/created and settings/document-updated, and recomposes any blank session whose preset differs from agentPresets.default. Non-blank sessions are left untouched.

This seems like a product gap rather than a configuration issue — reporting it here because Issues are disabled on this repository.

[NOirBRight]

Additional evidence from the published 0.1.6-alpha.2 Web client: this default-display / reused-blank-session mismatch is still reproducible at the preset-controller seam.

Observed user-visible symptom and durable record

The new-session screen displayed Standard mode. After sending the first message, the conversation header displayed PTC mode.

We inspected that exact conversation's durable log, read-only:

• The session header carries agentPreset: "ptc".
• Its creation timestamp precedes the first user message by approximately 5.5 days.
• Before the first turn, the log contains permission/sandbox/approval initialization and session/end-seed, followed by the first user message. There is no intervening preset-selection event in that initial sequence.

This is consistent with a pre-existing empty session being used for what the UI presents as a new conversation, rather than a model changing modes after the first message.

Isolated check against the installed release artifact

We evaluated the actual AgentPresetSeatController and presetOf code from the installed @deepseek-ai/dsh-client-ui-agent-preset@0.1.6-alpha.2 lib/client.js. Only the snapshot-store primitive, roster response, and remote selection endpoint were stubbed; no third-party plugin was loaded.

Inputs:

• Roster: standard is the default; ptc is available; mode selection is enabled.
• An unbound hero controller and a session-bound controller share the staged-choice object, as the shipped integration does.
• The receiving session is blank and has projectionValues.agentPreset = "ptc".

Results:

Action before binding the blank session	Hero display	Receiving session preset	select RPC calls
Leave the displayed Standard default untouched	standard	ptc	0
Explicitly select Standard	standard	standard	1

The first case deterministically fails the invariant that the mode shown for the new conversation is the mode actually used; the explicit-selection control passes.

Relevant shipped behavior

load() displays the Host-effective fallback when the hero has no session, but does not stage that fallback. Later, apply() with no staged id only updates the display from the receiving session and returns without calling agentPresets.select. Thus a displayed Standard default does not itself reconcile an older PTC blank session.

Scope / limitations

This is a release-artifact controller reproduction plus an actual affected session log, not a full browser/network replay. We did not capture the original creation request or prove every step of the live workspace-reuse path. The isolated result establishes that third-party plugins are not required for this mismatch; it does not establish the absence of every possible plugin interaction in the live installation.

Explicitly selecting Standard is a candidate workaround supported by the controller check, not yet browser-end-to-end validated. No official files or production configuration were modified.

This appears closer to #3018's stale blank-session preset than #7150's separate non-blank-session staged-choice discard path. A regression test should cover an unbound hero showing the default followed by an older blank session carrying a different preset, and assert consistency before the first prompt is accepted.