Delete session in the sidebar menu + double-click to rename (and a missing delete-session API underneath)

[ThomasNil]

Two small session-list UX gaps, plus a related API gap underneath them

1. No "Delete session" in the sidebar's per-session menu

The session row's ⋯ menu currently has Rename / Fork session / Archive session. There's no Delete. Given Archive already exists and explicitly keeps the session on disk, Delete feels like the natural missing sibling for someone who actually wants a session gone, not just out of the way.

2. Renaming a session takes two steps when it could take one

Today the only way to rename a session is ⋯ → Rename. A double-click on the row to jump straight into the rename dialog (same dialog, just one interaction instead of two) would match a pretty common pattern elsewhere (file managers, browser tabs, etc.).

The underlying gap: there's no official "delete a session" primitive at all

While looking into (1), I found that ISession (@deepseek-ai/dsh-client-runtime) only exposes prompt / cancel / rename / loadOlder / command / updateQueue — no delete. ctx.workspaces.delete() only removes a workspace from the list (and explicitly keeps the folder and session logs). There doesn't seem to be any official client-side or host-side way to actually delete one session's files.

Because of that, community session-manager plugins (e.g. @dshwp/dsh-session-manager) each have to implement their own custom host route for this from scratch — checking whether the session is currently running, evicting it from memory if it's live, removing it from persistence, etc. That's real business logic that every third-party plugin wanting this feature has to reinvent independently, with no shared, tested implementation to lean on.

Even if the two small UI additions above aren't a priority, an official ISession.delete() (or an equivalent host endpoint) feels like it'd remove a chunk of duplicated, easy-to-get-subtly-wrong logic from the plugin ecosystem.

Why a Discussion and not a PR

I put together a working local patch for both UI pieces (against the compiled dsh-client-ui-workspace package, calling a plugin's existing delete route as a stopgap for the missing primitive) to validate the idea end-to-end, but I don't have the monorepo's real TypeScript source / build pipeline set up to turn that into something submittable — so this is more "here's a gap + a rough sketch of the fix" than a ready PR. Happy to share more detail on what I tried if it's useful.

[liyangbing]

这个 Discussion 把 UI 缺口和更重要的 Host API 缺口分开了：archive 是可见性操作，不等于删除；在没有官方 delete transaction 之前，插件自行删 JSONL 或从 sidebar 移除都不能证明 Session 已安全删除。

我维护的独立 DeepSeek Harness 社区手册有一份对应的 Session archive/trash/delete runbook。在官方 primitive 出现前，建议社区实现至少按以下顺序验收：

• 先用 exact Session identity 检查是否仍有 live Agent/Host writer、pending turn、active stream 或其他客户端；
• 对完整 Session root 做只读快照和 hash，记录 workspace membership、archive state、log compression 形态及版本；
• 默认走官方 archive；若确实要回收磁盘，停止所有拥有该 root 的 Host，再把经过 header/sequence 校验的 artifact 移入带 generation 的 trash，而不是直接 unlink；
• 删除/恢复失败时保留原始 artifact 和错误证据，验证冷启动 list/search、workspace accounting 与 Session lineage，不要把“sidebar 消失”当成删除成功。

如果未来增加 delete API，最好让它成为 Host-owned、带 writer coordination 和可审计结果的事务；UI 的 Rename/Fork/Delete 菜单只是 presentation，不应自行定义生命周期语义。手册为独立社区资料，不代表官方 DeepSeek AI 项目。

[Jstn-1g]

I reproduced the lifecycle failure behind this API gap against exact dsh-v0.1.2-alpha.1 (cd5ef814). This is not an archiveSession() bug—archive intentionally accepts live Sessions—but it shows why a plugin-owned unlink + SessionStore.detach() sequence cannot implement deletion safely.

During a gated provider turn, the current Desktop/plugin sequence removed the Session from ctx.sessions while ctx.agents still held the same Agent; session/disposed fired, the provider AbortSignal remained un-aborted, and releasing the gate let the Agent complete through turn/end. After detachment, zero session/event callbacks fired even though the detached Session object's private log accepted the later appends. Persistence/UI observers therefore silently miss the remainder of the turn.

The exact versions, code chain, expected transaction, logs, and safe interim are documented in dsh-tauri-plugins #22. The safe conclusion for current plugins is to keep archive/unarchive but disable permanent deletion; a live-registry precheck alone is still racy with resume and cannot prove persistence writers have retired. A Host-owned cancel/quiesce/forget/delete transaction remains the maintainable seam.