GUI "New Session" silently resumes an old blank draft, making "settings apply to new Sessions" unreachable

[Akrtsh]

GUI "New Session" silently resumes an old blank draft, making "settings apply to new Sessions" unreachable

Observed on DSH 0.2.2-rc.1 (Desktop/Web), Windows.

Symptom. After enabling Settings → Subagents → allow Agents to choose a subagent model
(which writes subagent-model-selection-settings and is documented as affecting
subsequently created top-level Sessions), a user can click "New Session" repeatedly and never
obtain a Session that honors the new route list. list_subagent_models(provider=…) keeps
answering with the parent route only, and explicit provider/model on subagent is denied with
LLM provider "…" is not allowed for this Session.

Root cause (source-verified). "New Session" does not create a Session:

1. packages/client/ui-workspace/src/client/navigation.ts:234-250 — createInWorkspace() finds
   the workspace's first blank, unarchived Session and passes its sessionId to create
   (the interface comment at :84-91 states "New Session returns to that blank's unsent draft").
2. packages/api/session-controller/src/agent.ts:343-391 — claim() treats a named Session with
   no turn/start as reusable and calls agents.resume() rather than creating.
3. packages/core/session/src/index.ts:804-809 (agent-loop) → Session.fromRestore replays the
   stored log as seed; the constructor appends session/end-seed {} (:697-701) and freezes
   firstLiveSeq = log.length (:669).
4. packages/subagent/tool-subagent/src/model-selection-settings.ts:67-69 — the policy is only
   sampled when firstLiveSeq === 0 && eventAt(0) !== 'session/end-seed'.

So a blank draft created before the setting was enabled is resumed forever with
firstLiveSeq = 3 (its three pinned permission events), never qualifying. Policy is by design
written at creation only and never backfilled on resume — the 2026-08-24 note explicitly mentions
"including an explicitly empty restored Session" — so this is not a gate bug, but the UI makes
the documented semantics unreachable.

Why it is surprising. The blank draft's creation time is invisible in the UI, and the sidebar
label reads "New Session". Nothing indicates the click resumed a two-week-old draft. Users
reasonably conclude the setting is broken (it took several rounds of local diagnosis here,
including checking whether the branch/worktree mattered — it does not).

Reproduction.

1. Enable the subagent model-selection setting; keep a blank draft created before enabling.
2. Click "New Session", send one message, call list_subagent_models(provider="<allowed provider>").
3. Observe the denial; inspect the session log — seq 0-2 are permission/preset, sandbox/mode,
   approval/policy with the draft's original timestamp, seq 3 is session/end-seed with {},
   and no subagent/model-selection-policy exists.
4. Archive every blank draft in the workspace, click "New Session" again — the new Session has
   firstLiveSeq === 0 and receives the policy event. (Verified working workaround.)

Suggested fixes (either).

• On the first resume of a top-level Session that has no policy event, backfill the policy from the
  current settings (treat "restored but never used" as a creation).
• Make "New Session" mint a genuinely new Session when the reusable blank predates the current
  settings revision, or surface in the UI that the click resumed an existing draft.

Workaround for users who cannot upgrade. Archive all blank drafts in the workspace, or
force a new mint by starting where no blank exists. Existing Sessions without a policy cannot be
repaired client-side; agent.model.select (e.g. via a teammate-model helper) is unaffected by the
gate and is the only route-level workaround for them.

[Akrtsh]

GUI「新会话」静默 resume 旧空白草稿，使「设置只影响新建会话」的语义不可达

观察环境：DSH 0.2.2-rc.1（Desktop/Web），Windows。

现象。开启「设置 → 子智能体 → 允许 Agent 为子智能体选择模型」（写入
subagent-model-selection-settings，文档语义为只影响之后创建的顶层会话）后，用户反复点
「新会话」也拿不到一个遵守新路由表的会话：list_subagent_models(provider=…) 始终只返回父路由，
而 subagent 上显式传 provider/model 会被拒：LLM provider "…" is not allowed for this Session。

根因（源码核实）。「新会话」并不创建会话：

1. packages/client/ui-workspace/src/client/navigation.ts:234-250 —— createInWorkspace()
   取工作区内第一个未归档的空白会话，把它自己的 sessionId 传给 create
   （:84-91 的接口注释明说「New Session returns to that blank's unsent draft」）。
2. packages/api/session-controller/src/agent.ts:343-391 —— claim() 把没有 turn/start
   的具名会话当作可复用，走 agents.resume() 而不是新建。
3. packages/core/agent-loop/src/index.ts:804-809 → Session.fromRestore 把存储日志当作
   seed 回放；构造器追加 session/end-seed {}（session/src/index.ts:697-701）并把
   firstLiveSeq = log.length 固化（:669）。
4. packages/subagent/tool-subagent/src/model-selection-settings.ts:67-69 —— 政策只在
   firstLiveSeq === 0 && eventAt(0) !== 'session/end-seed' 时采样。

因此，在开关启用之前创建的空白草稿每次被 resume 都是 firstLiveSeq = 3（它的三个
permission 事件），永不满足条件。政策按设计只在创建时写入、resume 时从不回填——2026-08-24 的
设计笔记明确提到「including an explicitly empty restored Session」——所以这不是门控 bug，
而是 UI 让文档语义变得不可达。

为什么令人困惑。空白草稿的创建时间在界面上不可见，侧栏标签写的是「新会话」，没有任何地方
提示这次点击 resume 了两周前的草稿。用户会合理地认为设置坏了（本次本地排查为此花了数轮，
还一度怀疑与分支/worktree 有关——实际无关）。

复现步骤。

1. 开启子智能体模型选择设置；保留一个在开启之前创建的空白草稿。
2. 点「新会话」，发一条消息，调 list_subagent_models(provider="<allowlist 内的 provider>")。
3. 观察拒绝；检查会话日志——seq 0-2 是 permission/preset、sandbox/mode、approval/policy
   （时间戳是草稿的原始创建时刻），seq 3 是 session/end-seed、data 为 {}，
   且不存在 subagent/model-selection-policy。
4. 归档该工作区的全部空白草稿，再点「新会话」——新会话 firstLiveSeq === 0，能收到政策事件。
   （已验证此迂回有效。）

建议修法（二选一）。

• 顶层会话首次 resume 且无政策事件时，按当前设置回填政策（把「已恢复但从未使用」视同创建）。
• 让「新会话」在可复用草稿早于当前设置修订时真正新建一个会话，或在界面上明示这次点击
  恢复的是已有草稿。

用户侧迂回。归档工作区内全部空白草稿，或换到没有空白草稿的位置触发全新 mint。
存量无政策会话客户端无法修复；agent.model.select（如 teammate-model 之类助手）不受该门控
约束，是它们唯一的按路由迂回手段。

[2SinceJuly]

Your root cause analysis is correct on all four steps, and it's worth naming the consequence precisely: this isn't "settings are ignored", it's that a Session's route set is frozen at seed time and there is no UI path to a Session that has not been seeded.

Confirming the chain, plus one detail that makes the fix sharper. You cite Session.fromRestore replaying the stored log as seed and freezing firstLiveSeq = log.length. The important part is which log: a brand-new Session that was never given a turn still has an initial request/header recorded — the settings read happens when the Session is claimed, not when the first turn runs. So the draft that createInWorkspace() hands back is not "empty"; it's a Session whose route list was already resolved under the old settings. claim() at session-controller/src/agent.ts:343-391 treats "no turn/start" as reusable, which is true, but reuse is the wrong operation here — the hypothesis it's testing (this Session is blank, therefore nothing is lost by resuming it) doesn't hold for anything derived from settings at seed time.

Three ways to fix it, and I'd argue for the third:

1. Don't reuse seeded blanks. Have claim() require that the candidate has no request/header at all before resuming. Clean, but it changes the "New Session returns to that blank's unsent draft" behaviour at navigation.ts:84-91, which people may rely on to recover a typed message.

2. Version the settings into the Session. Record the settings revision that produced the seed, and on claim, if the revision changed, start a new Session instead of resuming. Correct, but needs a persistence change and a migration story for existing sessions.

3. Make "New Session" mean what it says, and keep the draft separately. The draft is a UI object, not a Session property. Persist the unsent draft keyed by workspace (it already round-trips through InputState), and have "New Session" create a genuinely new Session — seeding it under current settings — while restoring the draft text into it. That preserves the recovery behaviour you cite as the reason for the reuse and makes "settings apply to subsequently created Sessions" reachable.

(3) also fixes the wider symptom class, not just this one: any future setting that's read at seed time has the same unreachability problem today.

A workaround worth putting in the thread, since this will take a release to land: the settings are read at claim, so nudging the Session out of the "reusable blank" state should re-seed it. Concretely, sending one message and then using "New Session" gets a new seed — which is presumably why this doesn't affect people who use the GUI continuously. If you can confirm that, it's a useful diagnostic for whoever picks this up: it proves the state is the seed, not a cached settings value.

One question about the repro that would strengthen the report: does it reproduce when the blank draft is empty versus when it has unsent text? createInWorkspace() finds "the first blank, unarchived Session" — if the selection ignores draft content, the bug hits even with no draft, and the fix landscape changes (option 1 becomes much more attractive because there's nothing to preserve).

[Akrtsh]

Workaround confirmed. claim() reuses only Sessions with no turn/start (session-controller/src/agent.ts:372), and the list projection flips blank permanently on the first one (list.ts:51). An accepted message therefore removes the blank from the pool, and the next "New Session" mints a fresh Session that samples current settings. Two caveats: a rejected first prompt leaves the blank reusable (client/sessions/session.ts:307), and multiple pre-settings blanks are consumed one per click. Verified live on rc.1: archiving all pre-settings blanks produced a Session with the policy event.

Empty drafts reproduce too. Selection checks only summary.blank, cwd, workspace membership, archived state, and preset (ui-workspace/src/client/navigation.ts:238-244) — never draft content; drafts live in client InputState, not the session log. With no draft there is nothing to preserve, which favors option 1.

One version nuance: in rc.1, unused blanks' seeds contain only the three permission events; the initial request/header is appended in buildRequest (agent-loop/src/agent.ts:656), called only from the step path. The freeze-at-seed conclusion holds either way.

Option 3 agreed — it preserves draft recovery and closes the whole class of seed-time settings.

中文版本

迂回确认有效。 claim() 只复用没有 turn/start 的会话（session-controller/src/agent.ts:372），列表投影在首个 turn 时永久翻转 blank（list.ts:51）。因此一条被接受的消息会把空白草稿移出复用池，下次「新会话」铸造的新会话即按当前设置采样。两个前提：被拒绝的首条提示不消耗草稿（client/sessions/session.ts:307）；多个旧草稿每次点击只消耗一个。rc.1 活体验证：归档全部旧草稿后，新会话携带政策事件。

空草稿同样复现。 选择只看 summary.blank、cwd、工作区成员、归档状态、preset（ui-workspace/src/client/navigation.ts:238-244），从不看草稿内容；草稿存于客户端 InputState，不在会话日志。空草稿无可保留之物，这支持修法①。

一处版本差异： rc.1 中未用草稿的 seed 只含三个权限事件；初始 request/header 在 buildRequest（agent-loop/src/agent.ts:656）追加，仅由 step 路径调用。「设置冻结于 seed」的结论不受影响。

同意修法③——既保留草稿恢复，又关闭整类 seed 期设置问题。

[2SinceJuly]

Two things worth adding, both aimed at whether the fix is a one-liner or a redesign.

On the repro question I asked: the answer changes the fix, so it's worth confirming before anyone writes code. If it reproduces with an empty draft, createInWorkspace() is selecting on blankness alone and the draft-content preservation argument for option 1 collapses — then "don't reuse seeded blanks" is both the smallest and the correct fix. If it only reproduces when the draft has unsent text, then the draft really is the thing being preserved, and option 3 (draft as a UI object, separate from Session) is the only one that keeps both behaviours.

A cheaper workaround than archiving, worth putting in the report: the gate is firstLiveSeq === 0 && eventAt(0) !== 'session/end-seed'. A Session that has never been claimed still has firstLiveSeq === 0 — the seed only freezes it on first resume. So the first message sent into a draft picks up current settings if the settings changed since it was created, and only subsequent resumes are frozen. If that holds in your testing, the practical advice is "send the first message after changing settings, not before", which is much less destructive than archiving every blank.

If neither matches what you saw, that's itself a useful finding and the report should say so — it would mean the freeze happens earlier than fromRestore.