better-dsh-session-deletetool

Delete a conversation from DeepSeek Harness — DSH ships archive only.

中文说明

---

Why this exists

DSH can only archive a conversation. Archiving hides the row from the sidebar and keeps every artifact: the log, the workspace account, the projection checkpoint all stay on disk, and the conversation can be restored at any time. The persistence seam has no deletion API at all — @deepseek-ai/dsh-session-persistence-jsonl states it plainly:

Nothing deletes session files — logs accumulate under root until removed externally; the seam has no deletion API.

So a long-lived profile accumulates conversations forever. This plugin adds the missing step: a Delete conversation row in each session's ⋯ menu that really removes the data — and the dialog it opens is also the one place that shows a conversation's whole family before you touch it.

What it deletes

For the chosen session, the Host half:

1. removes the session's artifact directory — the current log, every retained historical format generation, and any session-local file in it (ctx.sessionPersistence.locate(header) gives the path);
2. removes the descendants you selected — child sessions are sessions of their own with their own logs. DSH records every child in its parent's header (SessionHeader.parentSession), and writes that field for every relation it creates: the Subagent runtime sets it with origin: 'subagent', a fork sets it with isSeeded, and Agent Teams resolves its roster through the same field. The plugin walks that lineage breadth-first and unions it with the durable subagentCatalog projection (ctx.subagents.listDescendants), so a child whose own header no longer reads is still named. Descendants are deleted deepest first, gathered before anything is removed, and only the ticked ones go — up to 200 per request;
3. drops the workspace account — the id leaves every Workspace record's sessionIds (Workspace.detachSession) and the registry-global archive and pin sets;
4. drops the projection checkpoint — the session_projcache domain record and its <id>.json file;
5. closes the shells the session owned — ctx.terminals are part of no admission family, and the service only reaps them when the Agent is released, which can be long after the log is gone;
6. tells connected pages — one api-session/removed per removed id, the same event the shipped Session controller emits when a Session is disposed, so the rows leave the sidebar immediately.

Seeing the family, and choosing what goes with it

The sidebar lists a subagent session and a derived conversation as rows of their own, and nothing there says which conversation spawned them; DSH itself never draws that relation. This dialog is the one place it is drawn: the session's whole family as one tree, the branches below the branches included.

…