会话生命周期管理的想法

[PPawnsir]

重度使用dsh一个月，也自行开发了一个多agent编排插件，目前发现有两个关于dsh会话生命周期设计缺失的问题
1、没有删除会话的通道，数据只能无限积累
归档只是执行门禁（拒绝跑模型），数据全留；删工作区明确保留会话记录；三个核心包里不存在 deleteSession API（0.2.0-rc.2 源码实证）。
实机影响：重度使用 6 周积累 3400+ 会话目录 / 1.5GB；宿主启动随会话数变慢；一次性子代理生态（任务看板类插件）每周产生数百死会话，无官方处置通道。
请求：deleteSession 一等 API（明确活体/休眠/子代理血统/派生存储的语义）+ GUI 删除入口 + 插件作者生命周期指南

2、「N 个子智能体」计数 = 历史累计 spawn 数，删除子会话后不降

删除某根会话的 193 个已结算子会话目录（磁盘 3431→3238），重启宿主（新进程晚于删除 48 秒），计数纹丝不动；被删 id 在 storages 里零残留——枚举显然来自根会话 append-only 日志里的 spawn 事件链，语义是「历史上生过多少」而非「现存多少」。
建议：拆分显示「现存 X / 历史 Y」，或提供注册面与磁盘对账的 prune 路径。

[MalikAhed]

The two observations point to separate lifecycle counters that should be made explicit rather than inferred from the same append-only session log.

For deletion, I’d make deleteSession(sessionId, { descendants: 'none' | 'all', purgeDerived: boolean }) a first-class host API with a dry-run response listing live sessions, archived sessions, child sessions, and bytes to be removed. The GUI can expose “Archive” and “Delete permanently” separately, require confirmation for descendants, and leave an audit/restore record until the purge completes. Plugins should use the API instead of deleting storage directories directly. A background purge queue would avoid making startup or the UI wait on thousands of files.

For the agent count, expose two values: activeDescendants and spawnedDescendantsTotal. Derive the first from the current session registry/storage and keep the second as an immutable historical metric. If a prune operation removes child records, the active value should drop while the historical value remains unchanged; label the UI accordingly so “N agents” does not imply live agents. Add tests for deleting a settled child, restarting the host, and reconciling the registry against storage.

This gives plugins predictable lifecycle semantics and prevents unbounded session growth without losing audit history. If this addresses the design gap, could you please click GitHub’s Mark as answer on this reply?

[PPawnsir]

Small note: this discussion isn't in a Q&A category on my end, so GitHub doesn't offer me a "Mark as answer" button — but consider this reply the answer as far as I'm concerned. 👍

[argszero]

Source-verified answer. Both observations hold, and the second one is a property of a fold rather than a cache bug.

1. No deletion channel — confirmed, and it is wider than the three packages you checked. The public storage contract is SessionPersistence (packages/session/session-persistence/src/index.ts), and its entire abstract surface is create (:152), open (:167), flush (:180), stat (:196) and list (:203). No delete, remove or purge member exists anywhere in the package, and no other package exposes one: the session-query family documents read/search/export only, and the sqlite index's own row removal is index maintenance, not a session API. "Data can only accumulate" is therefore a property of the contract, not a missing call.

One half of your proposal is already expressible today, which matters for the design: SessionPersistenceSnapshot (:50) carries header, revision, eventCount and sizeBytes per session. A dry-run inventory — how many sessions, how many bytes, which identities, live or dormant — needs no new core surface; only the removal does. The liveness discriminant also exists: open(id, 'write') throws SessionAlreadyOwnedError while another owner holds the session, so "live" is readable without touching the filesystem.

2. The "N subagents" number is a fold over the event log, not a census of storage. The client accumulates it in packages/client/ui-chat/src/client/conversation-nodes/turn-process.ts:184: on every tool/call event whose tool is a subagent-delegation tool, subagentCount: current.subagentCount + (subagent ? 1 : 0). It is monotonic over the conversation event stream and consults no directory anywhere; the server-side counterpart (packages/subagent/subagent/src/projection.ts, the subagent and subagentTiming projection keys) folds the same append-only events. Deleting 193 child directories therefore cannot move it — the number answers "how many delegations has this root ever made", and your 3431 → 3238 measurement is exactly what a fold with no reconciliation step produces. Splitting it into "existing X / historical Y" is a projection plus UI decision, and the "existing" half would need registry-to-storage reconciliation that does not exist today.

3. Plugin-mountability, since we screen for it every round. Read side: a plugin can enumerate via list() and probe liveness via open(id, 'write'), as above. Write side: no. deleteRecord (packages/storage/storage/src/backend.ts:110) is a per-record operation owned by the unit that declared the table, sessions are laid down by the jsonl persistence backend as one directory per session, and the filesystem service has no unlink primitive at all (ctx.fs offers content mutation, discussion #5461). A plugin could therefore only delete by unlinking directories behind the backend's back — which is exactly the unsafe pattern you are asking to have replaced. Recorded on our side as a core API gap rather than a plugin gap.

For context, this is the second report on this axis we have seen: #5696 / #5995 describe the in-memory half — a hydrated session registry entry is dropped only when its owning scope tears down, so a long-lived process grows monotonically. Delete-on-disk and evict-in-memory are the same missing retention policy seen from two sides, which is why they probably want one design rather than two patches. We have no published asset that touches deletion; the closest thing of ours only reads logs (session-audit, integrity and path-identity auditing) and deliberately writes nothing.

[PPawnsir]

Thank you both — these two replies compose into a complete picture.

On the merits, I'd treat them as complementary layers rather than two competing answers:

• Diagnosis: the source-verified reply is authoritative. "No deletion is a property of the SessionPersistence contract (create/open/flush/stat/list), not a missing call" and "the subagent count is a fold over the event stream (turn-process.ts:184), not a census of storage" are both confirmed by our on-disk experiments — our 3431→3238 directory drop with an unmoved counter is exactly what a fold without reconciliation produces.
• Design: the first reply's shape (deleteSession with descendants/purgeDerived, dry-run inventory, background purge queue, split activeDescendants/spawnedDescendantsTotal) is the right direction, with one correction from the second reply: the "active" half of the counter can't be derived from the registry today — it needs the registry↔storage reconciliation step to be built first.

Two follow-ups from our side as the reporting plugin authors:

1. We've already adopted the SessionPersistenceSnapshot surface (sizeBytes/eventCount) for our dry-run inventory instead of walking directories ourselves — thanks for pointing at :50.
2. Fair point on our workaround being "unlinking behind the backend's back": our cleanup is deliberately scoped (only sessions our plugin spawned, four safety gates, dry-run default, path-escape guards), but we agree it's a stopgap — we'll migrate to deleteSession the moment it ships, and we're happy to be a testing consumer for the API.

Happy to click Mark as answer on the design reply if the combined reading above lands in the thread as well — both halves deserve to be on record for whoever implements this.