[feature]希望新对话可以保留未发送出去的草稿

[lgzzzz]

在当前的0.2.1alpha4版本中，在任意工作区中新建对话，输入一部分消息，在未发送的情况下，切换到其他会话，新会话条目从左边栏消失，再次点击新会话后，之前未发送的输入了一部分的草稿消息丢失了。

我们有可能会有以下工作场景，新建会话，输入了一部分消息，需要到其他会话中看一下其他会话中的消息(可能是agent输出的一些结论或者某些文件路径，或者某些看一遍记不住的重要信息)，于是我们切换到其他会话，再次切换回新会话，继续输入消息。

由于新会话无法保留草稿，以上的工作流程会被打断，不得不在一个其他的地方输入消息(比如其他编辑器输入消息)，在各个会话中来回切换后，在其他地方完成输入消息后，再把消息复制到新会话中进行发送。

在以前的版本中，我记得新会话是被保留的，就算中途切换到其他会话，再次切换回来，之前没发送的消息是仍然存在的。

[argszero]

Thanks for a very concrete report — and you are right, and it is a regression: the plain New Session entry stopped reusing the blank Session in dsh-v0.2.1-alpha.2. I traced both halves of the symptom to the source; below is where each one lives, exactly where the reuse was lost, and how to get your text back today.

1. A draft is stored per Session id, not per conversation

The draft is not thrown away — it is keyed to a Session id:

• packages/client/ui-conversation/src/client/stores.ts:8 declares the key prefix const CONVERSATION_STORE_KEY = 'dsh.conversation'; :25 persists the conversation store under it;
• stores.ts:43-51 reads one Session's value back with localStorage.getItem(\${CONVERSATION_STORE_KEY}.${sessionId}`)`;
• the write side is continuous, not on submit — input/facade.ts:937-945: after every input dispatch, publish() compares the fresh draftSnapshot with the last one and calls this.persistDraft?.(draft) only when it changed (publish() runs from run(), facade.ts:679-682);
• the read side is input/hub.ts:170 — when a Session's input shell is created, shell.setDraft(readConversationDraft(binding.sessionId)).

So everything hangs on one question: does the same Session id come back? The stored text is never discarded; it is left under an id that nothing points at any more.

2. Why the row leaves the sidebar

That part is deliberate. packages/client/ui-workspace/src/client/tree.ts:245:

if (session.blank && session.id !== current) return false

current is the Session the main view retains (tree.ts:38-41). The contract says it in three places: tree.ts:232-234 ("Ordinary sessions are visible; among blank sessions, only the current one is visible"), tree.ts:425-426 ("Blank sessions are excluded except for the selected provisional New Session row"), and tree.ts:474 ("only the current blank"). A never-prompted Session is a provisional placeholder that is a list member exactly while it is the selection — switch away and it leaves the tree by design, without being archived and without any event telling you it went.

3. Why "New Session" does not come back to it — the actual defect

Every plain New Session entry point calls startSession with no options: the session.new command (ui-workspace/src/client/shortcuts.ts:81-82, default ⌘N / Ctrl+N), the sidebar button (ui-sidebar/src/client/SidebarRoot.tsx:249 and :265), the header button (ui-sidebar/src/client/HeaderLeadingControls.tsx:48). In ui-workspace/src/client/navigation.ts:

• :320-324 — with no options draftOptions stays undefined, so initializeDraft is false;
• :343-344 — draftOptions === undefined ? this.openWorkspaceSession(target, undefined, undefined) : …;
• :288-296 — openWorkspaceSession calls connectBlank(workspaceId, reuse);
• :209 — and there it stops:

if (reuse === undefined) return this.sessions.create({ workspaceId })

The blank-reusing branch is the other one — createInWorkspace (navigation.ts:220-233), which names the first eligible blank:

const blank = sessions.ids.find((id) => {
  const summary = sessions.byId[id]
  return summary !== undefined && summary.blank && summary.cwd === workspace.path
    && workspace.sessionIds.includes(id) && !archived.includes(id)
})

It is reached only when reuse !== undefined. So an option-less New Session mints a brand-new Session id every press; the new Session's storage key is empty, and your draft stays behind at dsh.conversation.<the old id>.

The reuse machinery itself still works — you can see it from the other side. The picker that starts a Session in a chosen Workspace passes options: startSession(workspaceId, { clearPreviousDraft: false }) (rows/WorkspaceBrowser.tsx:1375-1378). Any options object takes the draftOptions !== undefined path into openWorkspace → connectBlank with a reuse value → createInWorkspace → the same blank comes back, and hub.ts:170 restores its draft. Startup restoration does the same thing (restoreBlank, navigation.ts:255-274). The behaviour you remember is still in the code; the plain entry point simply stopped using it. The two documented in navigation.ts:82: "Create a fresh Session, or reuse a blank when preparing an explicit draft."

4. Where the regression came from

One commit carries it:

55dfd3bab1  fix(plugins): narrow optional bundles and create fresh session agents   2026-10-06

Before that commit, connectWorkspace was documented "Resolve the reusable or newly created blank Session for a Workspace", and startSession's option-less path went openWorkspace → connectWorkspace → that same reuse. The commit introduced the flag and passed false from the plain path (+ if (!reuse) return this.sessions.create({ workspaceId }), + ? this.openWorkspaceSession(target, undefined, false)), and a later refactor (3c1e357132, 2026-10-09) turned the boolean into the preset object while keeping the meaning — that is where today's reuse === undefined early return comes from.

By release: dsh-v0.2.1-alpha.1 does not contain the commit (the last version where a plain New Session reused the blank); dsh-v0.2.1-alpha.2, alpha.3, alpha.4 and alpha.5 all do. That matches your "in earlier versions this was preserved".

I checked every line above on both your build (dsh-v0.2.1-alpha.4) and current master: the four files involved (navigation.ts, tree.ts, stores.ts, facade.ts) are byte-identical between them, so this is unchanged in alpha.5 too.

5. Recovering the text you have already lost

It is still in your browser storage. In the desktop app (or the web UI) open DevTools and list the conversation keys:

Object.keys(localStorage).filter(k => k.startsWith('dsh.conversation.'))
  .map(k => [k, localStorage.getItem(k)])

Each value is JSON of { draft, view, viewRequest } (stores.ts:24); draft is { text, references } (input/draft.ts:41-48, or a plain string in older data). .draft.text is what you typed — copy it into the new composer.

Two limits worth knowing. Inline reference chips survive as well (they are carried in references), but attached files and images do not: attachments are runtime-only (service.ts:160 keeps them in a draftAttachments map; facade.ts:604-622 returns them on dispose and hub.ts:156-161 releases them), only their ids ever entered the input state, and the input state is not part of the stored draft.

6. Where the fix belongs

Two small client-side changes, either of which closes it, and neither one touches the "an empty blank row is provisional" rule:

1. Let the option-less New Session reuse an eligible blank when that blank still holds a stored draft — i.e. route session.new through the same reuse the Workspace picker already uses (navigation.ts:209); or
2. Keep a non-current blank row visible while its stored draft is non-empty (the predicate at tree.ts:245 is the only gate).

(1) is the smaller change and matches your expectation exactly; it also makes the ⌘N path agree with the Workspace-picker path, which today behaves differently for no stated reason.

One note in case a client-side rescue is preferred over the core change: the write face is public — IConversation.input (ui-conversation/src/client/service.ts:42, exported from the package's client index) carries requestDraftInitialization(binding, options) and for(actx).setDraft(text) — so a client plugin could re-apply an orphaned draft. The hard half is the trigger: the app emits no "a blank Session is going away" signal, so that route is a stopgap, not the fix.

[argszero]

Correction to my earlier reply

I called this a regression. The mechanism and the recovery steps above stand, but the framing was wrong, and one of the two fixes I proposed is the wrong fix.

The option-less New Session path did not lose an argument — it was changed on purpose, and the change shipped with an upgrade guide in the same commit:

docs/upgrade-guide/v0.2.1-alpha.1/new-session-generations/guide.md — "New Session creates a fresh Session and Agent using the current preset definition. It previously reused an existing empty Session in the workspace, which could retain an earlier preset definition."

The commit is 55dfd3bab1 (2026-10-06); the first release containing it is dsh-v0.2.1-alpha.2 (dsh-v0.2.0-rc.2 and dsh-v0.2.1-alpha.1 do not contain it). So the boundary in my earlier reply was right and the conclusion drawn from it was not.

What that invalidates: my suggestion 1 — "let the option-less New Session reuse an eligible blank when that blank still holds a stored draft" — gets the draft back by re-opening the path the change exists to close. On the Host, a preset-less create reuses a blank that is already live under the same preset id without re-mounting it (api/session-controller/src/agent.ts:262-266, :520), so the Agent keeps the preset definition it was built with.

What survives: the defect is that the change also moved which storage key an unsent draft lives under, with no migration and no signal (tree.ts:245 simply stops listing the blank). Suggested fix 2 — keep a non-current blank visible while its stored draft is non-empty — is still valid.

The better fix, and the accurate version of this analysis, is in a later report of the same defect: #10021 — create the fresh Session, then hand the orphaned draft over to its new id before the shell mounts.

[akol1]

Update: a patch keeps the draft while keeping fresh New Sessions

The request here — keep an unsent draft when the user leaves a new chat — now has an implemented fix without restoring the 0.2.0 blank-reuse behavior, which the 0.2.1-alpha.2 upgrade guide deliberately retired.

An option-less New Session still opens a fresh Session; before that Session's selection publishes, ui-workspace offers the Workspace's abandoned blanks to conversation.input.handOffDraft, which moves the newest unsent text, reference chips, and command chip into the new composer and saves it under the new Session's dsh.conversation.<sessionId> record. A target that already holds input keeps both drafts, and attachments stay with the Session that owns them.

The fix and its evidence are on the draft-regression thread: #10021. pnpm run typecheck and pnpm run build pass, 146 focused client unit tests pass, and the browser e2e scenario that types a draft, starts a New Session, and reloads the page passes.

[Alaric-L]

补充一个上面的评论没有覆盖到的点：不只是把文字从 localStorage 里读出来，还可以把那个被遗弃的会话重新打开，让草稿回到输入框。

1. 打开 DevTools——打包版桌面端按 F12（Windows 也可 Ctrl+Shift+I，macOS ⌘⌥I）即可；快捷键挂在隐藏的 toggleDevTools 菜单项上（见 apps/desktop/README.md 的 "including in packaged builds"）。

2. 找到被遗弃会话的 id：dsh.conversation.<id> 中 draft.text 是你那段文字的 key。

3. 把启动选择指向它再刷新：

   localStorage.setItem('dsh.sessions.current', JSON.stringify({ sessionId: '<id>' }))
   location.reload()

   启动恢复时 restoreSelection 会把"已保存的空白会话"作为恢复目标，restoreBlank 指名该 session id（packages/client/ui-workspace/src/client/navigation.ts:457-459），Host 复用同一会话，InputHub.shellFor 再从 dsh.conversation.<id> 把草稿灌回输入框（packages/client/ui-conversation/src/client/input/hub.ts:170）。文字和内联引用胶囊都会回来；附件/图片不会（它们是运行时对象，从未进入草稿记录，同附件相关的几条讨论）。

4. 设置后立刻刷新；刷新前的任何应用内导航都会把 dsh.sessions.current 覆盖回去。

已在 687f282e86（0.2.1-rc.2，桌面端）独立复现。同题报告：deepseek-ai/deepseek-harness#10021、deepseek-ai/deepseek-harness#10223。