Sessions can be archived but never deleted, and cannot be unarchived

[xiaowei2025cqu23phy]

Summary

A session can be archived from the sidebar context menu, but there is no way to delete a session and no way to unarchive one. Archiving is therefore an irreversible, one-way operation performed from a three-item menu — and archived sessions become completely unreachable through the UI.

What the UI actually offers

The session row menu in dsh-client-ui-workspace defines exactly three items:

const sessionMenuItems = [
  { id: "rename",  label: t("rename") },
  { id: "fork",    label: t("menu.fork") },
  { id: "archive", label: t("menu.archiveSession") },
]

There is no delete item. onDeleteRequest exists in SessionTree, but it is wired only to workspace deletion (onDeleteRequest(group.workspaceId, group.label)), never to a session.

Archiving hides the session everywhere

sessionVisible is the single predicate used by the grouped view, the flat list, and search results:

function sessionVisible(session, current, archived) {
  return session.origin !== "subagent"
    && !archived.has(session.id)
    && (!session.blank || session.id === current)
}

So once a session ID is in archivedSessionIds, it is excluded from:

• deriveGroups (grouped sidebar view)
• deriveFlat (flat sidebar view)
• deriveSearchResults (search — archived IDs "never match")

There is no "Archived" view, no filter to reveal them, and no unarchive action anywhere in the client.

Why this is a problem

1. Archive is an unrecoverable misclick. The menu is three items deep and 归档会话 sits directly under 派生. A single wrong click silently removes a session permanently from the user's reach, with no confirmation dialog and no undo.
2. Archived sessions accumulate as dead IDs. archivedSessionIds is an append-only set in the workspace registry state; nothing ever prunes it. Even after the underlying session data is gone, the ID remains.
3. Users cannot reclaim disk space. Without a delete, the only path is editing workspace.json and the sessions/ directory by hand while DSH is closed.

Real data from one install running @deepseek-ai/dsh 0.1.5-rc.3:

archivedSessionIds : 94 entries
  on disk          : 26 sessions (1.3 MB)
  stale (no data)  : 68 entries

68 of 94 archived IDs point at sessions that no longer exist — pure accumulation, with no supported way to clear them.

Suggested changes

1. Add Delete session to the row menu. A destructive action needs to exist. Delete the session directory (sessions/<workspace>/<id>/) and drop the ID from archivedSessionIds and from the workspace's sessionIds.

2. Add Unarchive, or an "Archived" section. Archiving should be reversible: either

• an unarchiveSession(sessionId) command mirrored from archiveSession, surfaced as "Restore" in the menu when a session is archived; or
• a collapsed "Archived" group at the bottom of the sidebar that lists archived sessions with a Restore action.

3. Consider confirming the archive action. Given that it is irreversible in the current build, a confirmation step (or at least a toast with "Undo") would prevent the accidental case.

4. Prune stale IDs. If a session's data is absent, its ID need not stay in archivedSessionIds forever.

Workaround (for anyone hitting this today)

Close DSH completely, then edit $DSH_HOME/storages/workspace.json:

{ "global": { "archivedSessionIds": [] } }

and optionally remove the matching directories under $DSH_HOME/sessions/<workspace>/. Reopen DSH. Editing while DSH is running does not stick, because the in-memory workspace state is written back over the file.

Environment

• @deepseek-ai/dsh 0.1.5-rc.3
• Windows 11, DSH Desktop
• Session storage: dsh-session-persistence-jsonl (.zstd)

Happy to test a patch if the direction is acceptable.