[0.2.1-rc.2] Draft text is lost when switching sessions

[Saneman1-kz]

Problem

We start a new session (using the "New session" button), type part of the text, then switch to another session (there's often a need to copy something from another session — a file name or some other identifier), and the newly typed text disappears and has to be typed again. We end up having to type the text on the side and then copy the fully typed text over, which is very inconvenient.

Proposal
I don't know what the best approach would be, but it would be good to support this user use case.

[argszero]

The text is not discarded — it is still in localStorage under the old session's id. What is missing is the way back to it: leaving a never-sent session removes the only row that could take you there, and the "New session" button then mints a new id instead of reopening that one. There is also a reusable-blank path in the same file that would fix this, and the button is the one caller that does not take it. Verified on 687f282e86 (0.2.1-rc.2).

Where the text goes

Each draft is persisted per session id as you type:

• packages/client/ui-conversation/src/client/stores.ts:43 — readConversationDraft(sessionId) reads dsh.conversation.<sessionId> and parses stored.draft.
• packages/client/ui-conversation/src/client/input/hub.ts:170 — shell.setDraft(readConversationDraft(binding.sessionId)), i.e. the draft is re-seeded whenever a shell is built for that id.
• Disposing the shell does not clear it (input/facade.ts:604 releases attachments and listeners only), so switching away writes nothing destructive.

Two things confirm it survives rather than evaporates: reloading the page while still in that session brings the text back, and the key is still in DevTools afterwards — localStorage["dsh.conversation.<old-id>"]. That is the quickest way for anyone to see this is a navigation bug, not a data-loss bug.

Why you cannot get back

Two independent choices combine:

1. The row disappears. packages/client/ui-workspace/src/client/tree.ts:245 — if (session.blank && session.id !== current) return false, documented just above as "among blank sessions, only the current one is visible". A session stops being blank once it is engaged (api/session-controller/src/client/sessions/manager.ts:297, effectiveBlank), so a draft alone never earns it a row.
2. "New session" does not reopen the blank it just left. The button calls startSession() with no arguments (ui-sidebar/src/client/HeaderLeadingControls.tsx:48, SidebarRoot.tsx:249/:265), which reaches openWorkspaceSession(target, undefined, undefined) (navigation.ts:344) → connectBlank(workspaceId, undefined) → if (reuse === undefined) return this.sessions.create({ workspaceId }) (navigation.ts:209). A brand-new id, every click.

That last branch is the defect. connectBlank takes a reuse preset precisely so it can search for an existing blank in the workspace — navigation.ts:223 scans sessions.ids for summary.blank && summary.cwd === workspace.path && workspace.sessionIds.includes(id) and names it, letting the Host hand the same session back. The startup path reaches it (connectWorkspace defaults its options to {}, navigation.ts:193), and the preset picker reaches it (ui-agent-preset/src/client/index.ts:204, { clearPreviousDraft: false, agentPreset: 'cordis' }). The New Session button is the one caller that passes nothing and therefore always creates.

So the asymmetry is a single call site:

entry point	reaches createInWorkspace (reuse)	draft survives
startup / connectWorkspace()	yes — options default to {}	yes
preset picker	yes — explicit options	yes
New Session button / startSession()	no — reuse is undefined	no row, new id

The handover that already exists is the wrong tool here

There is a working draft-transfer implementation in the same tree — ui-conversation/src/client/apply.ts:358-378, wired into the selectWorkspace callback: it reads from.draftSnapshot, moves the text with next.setDraft(draft) / from.setDraft(''), and carries attachments via rebindDraftFiles. startSession even has the hook for it (beforeOpen, navigation.ts:344), but only passes a callback when an explicit prompt/clearPreviousDraft option is given.

It is tempting to reuse that for the New Session button, and it would be wrong for your scenario: you switch away to copy an identifier and then want to come back to your text. Handover moves the text into the other conversation — the draft would follow you into a session you did not mean to write in. The mechanism fits "replace where I am typing", not "park this while I look at something".

What I think the fix is

Make startSession() take the reuse path it already has — pass the same preset object the preset picker passes instead of undefined — so clicking New Session returns to the standing blank, whose id still owns the draft, and readConversationDraft seeds the composer. That is a one-argument change at navigation.ts:344, it removes the orphan id per click, and it makes the button agree with the two other entry points. The second-order benefit is that the blank row stays current across the whole round trip, so the user never sees it vanish.

If the intended reading is instead "a blank with content should stay visible in the tree", that is a different change with a different cost: sessionVisible would need draft presence in the summary, which the Host does not currently project (the row state comes from blank, origin, archive and pin — tree.ts:239-256). I would not start there; the reuse fix delivers your use case without a new summary field.

Two smaller observations while tracing this:

• Keys are never garbage-collected. Nothing in the client calls the conversation store's clearPersisted(); a send writes an empty draft over the current key instead (input/facade.ts:554), so old ids keep an empty record rather than growing. Every orphaned New Session click leaves one behind — harmless in size, but it does mean the number of dsh.conversation.* keys only ever rises.
• The empty-draft case is worth deciding explicitly: if startSession() starts reusing blanks, a user who clicks New Session twice in a row with nothing typed gets the same session twice, which is the right answer but should be asserted, not assumed.

One question that decides which of the two fixes is the intended one: when you switch away mid-draft and later click "New session", would you expect to land back on the text you left (reuse), or to get a clean session with the old text still waiting somewhere (a visible draft row)? The first is the cheap change; the second is the more honest model if drafts are meant to be first-class.

[argszero]

Correction to my comment above — the headline fix I proposed is wrong, and the repository says so in a file I should have read before writing it.

What I got wrong

I framed "startSession() does not take the reusable-blank path" as the defect. It is documented intent: docs/upgrade-guide/v0.2.1-alpha.1/new-session-generations/guide.md states that New Session creates a fresh Session and Agent using the current preset definition, that "Client calls to uiWorkspace.startSession(workspaceId) follow the same behavior", and that only workspace reconnection through openWorkspace/connectWorkspace reuses an eligible blank. The reason is concrete: reusing an empty session could retain an earlier preset definition, so an edited preset would not be applied.

Making the button reuse the blank therefore would not be a one-argument fix — it would reinstate the behaviour that guide retired. The Host's reuse rule runs the requested preset, or the configuration default when the request names none, and does not resolve the preset the blank recorded; and when the target is already the current live agent it is returned without re-mounting. A live blank that is already on the default preset would come back exactly as it was, with its old composition. So the change would trade a lost draft for a stale agent, which is the worse of the two.

What still holds from the first comment

• The draft is persisted, not discarded: stores.ts:43 reads dsh.conversation.<id>, input/hub.ts:170 re-seeds it when a shell is built, and disposal does not clear it (input/facade.ts:604).
• The row leaves the tree by design (ui-workspace/src/client/tree.ts:245), so after switching away there is no navigation target back.
• localStorage["dsh.conversation.<old-id>"] still holds the text — that part is actionable for anyone hitting this today.
• Attachments are not recoverable, only text and inline references; they are runtime-only and were never in the persisted snapshot.

The finding that replaces it

Tracing this properly turns up a narrower and more useful gap: the public entry point cannot express the combination this use case needs. startSession(workspaceId, options) (navigation.ts:320) computes draftOptions from options, and then always hands a non-undefined reuse preset onward whenever options was supplied at all — agentPreset === undefined ? {} : { agentPreset } (:344). An empty object is still not undefined, so any options object, including one that prepares nothing, lands in the reuse branch (connectBlank → createInWorkspace). Omitting options entirely is the only way to get a fresh Session.

So today it is either:

• no options → fresh Session, old draft stranded under an id nobody can reach;
• any options → reuse, correct draft behaviour, stale preset composition.

There is no "fresh Session, carry the draft across". That is the actual gap, and it does not conflict with the guide: the guide's third sentence even preserves the exception ("Calls with draft-preparation options preserve their existing reuse and content rules"), which is precisely the coupling that makes the missing case inexpressible.

Suggested direction, revised

Add an explicit opt-in that keeps fresh creation and moves the content: have startSession pass a beforeOpen (navigation.ts:288-296 already accepts one, and the draft branch at :345-349 already uses it) that hands the current shell's draftSnapshot to the new session — the same primitives selectWorkspace uses in ui-conversation/src/client/apply.ts:358-378. The option has to be separate from agentPreset, because agentPreset's presence is what selects reuse today.

One caveat on the handover shape, since it is my own earlier objection: moving the text into the next session is wrong for a user who leaves to copy something and comes back. The opt-in therefore needs a destination — the standing blank, keyed by workspace, restored when that session is reopened — rather than "whatever session is opened next". That is the design question worth settling before code: is an unsent draft attached to a Session, or to a Workspace? Today it is the Session, and that is the choice producing this report.

Sorry for the extra round trip; the first comment's mechanism sections are sound, its recommended fix was not.