[Bug] Deleted/modified agent preset ("Mode") strands recorded sessions after host restart: preset "X" not found

[BigUncle]

中文

删除或修改模式（Agent Preset，agent 预设）后，使用该模式的会话在宿主重启后无法恢复

摘要

会话创建时记录所用模式，每次恢复都按记录重新挂载。当该模式后来从名册消失——$DSH_HOME/.agent-presets 下对应目录被删除、改名，或模式被修改后不再以原 id 出现在名册——宿主一旦重启，所有记录了该 id 的会话都以笼统的 internal 错误恢复失败，且没有任何受支持的手段让这些对话继续。

同一进程内其实已经容忍删除：AgentPresets.remove() 会为已挂载会话保留 standing mount（见 packages/preset/agent-presets/src/index.ts 中 remove() 上方注释）。缺口只在冷恢复路径：宿主重启后，磁盘上已不存在的模式无法再被挂载。

环境

• dsh 0.1.1-rc.2（npm 全局安装），profile web
• Node v24.19.0，Windows 11（10.0.26100）

复现步骤

1. 新建一个用户模式：~/.dsh/.agent-presets/router-standard/agent.cordis.yml（拷贝任意内置预设即可）；
2. 在该模式下建会话并跑至少一轮，然后停止会话；
3. 删除、改名该目录，或修改该模式使其 id 从名册消失；
4. 重启宿主，打开该会话（或点模式选择器触发懒恢复）。

实际结果（本次复现，完整错误信息）：

模型操作失败：internal: resume failed for session "session-2c50143f-cf3e-4236-a0ee-d462bb2e605e": Error: agent-presets: preset "router-standard" not found (available: standard, code, minimal, cordis, liangshen)

（liangshen 是该宿主上既有的用户模式，其余四个为内置预设。）同一消息也出现在 RPC 的 error.message 里：

{
  "ok": false,
  "error": {
    "code": "internal",
    "message": "resume failed for session \"session-2c50143f-cf3e-4236-a0ee-d462bb2e605e\": Error: agent-presets: preset \"router-standard\" not found (available: standard, code, minimal, cordis, liangshen)",
    "details": {}
  }
}

UI 仅弹出这个“模型操作失败”开头的笼统提示，该 id 下所有会话永久卡死。实测一个真实环境里 78 个持久会话中有 20 个因单个被删 id 而搁浅。

期望结果：要么会话仍可恢复（有文档化的降级），要么给出结构化、可行动的错误与恢复路径，而不是笼统 internal。

根因

恢复链路：api-proxy.ts 的 composeAgent(presetId) -> presets.resolve(id) 抛 UnknownPresetError（preset.ts）-> 被 packages/api/remotes/src/agent-lookup.ts 的兜底捕获包装成 { code: 'internal' }，丢弃了线协议已定义的 agent-preset-not-found 结构化细节（{ agentPreset, available }）。

对比之下冷读历史已经优雅降级（standingKeyFor 失败被吞掉、历史仍可查看），唯独恢复硬失败，行为不一致且难排查。另外持久层已具备显式改绑的全部机制（agent-preset/selected 事件、最新者胜），只是没有暴露给搁浅场景。

修复方向建议

1. 最小改动：让恢复路径透传 agent-preset-not-found（而非 internal），客户端即可提供恢复入口；
2. 恢复流：报错时允许客户端为会话追加一条 agent-preset/selected 事件以改绑到现有模式——与空白期 agentPreset.select 同一持久化机制，扩展到搁浅场景；
3. 文档化回退：缺失 id 解析为部署默认组合（ghost id 下），并输出告警。下方插件证明该方案端到端可行。

已验证的进程内 workaround

通过 home patch 层挂载的小插件包裹服务实例的 resolve：未知 id 返回默认模式行（保留 ghost id 作隔离键），全部消费路径随之降级，20 个搁浅会话无需重建任何目录即恢复。核心代码见英文节。

已检索的既有报告

Discussions/Issues 中检索 preset not found、resume failed、“删除预设 会话”均无重复；最接近的是 #3018（改默认预设对复用空白会话不生效），同属预设生命周期领域但症状不同。

---

English

Summary

A session records the agent preset it was composed under — the same thing the UI calls a "Mode" — and re-mounts that preset on every resume. When the preset later disappears from the roster (its user-authored directory deleted or renamed under $DSH_HOME/.agent-presets, or the preset itself modified), every session recorded under that id fails to resume with a generic internal error after a host restart, and there is no supported way to keep those conversations alive.

In-process behavior already tolerates deletion - AgentPresets.remove() keeps standing mounts for joined sessions (packages/preset/agent-presets/src/index.ts, comment above remove()). The gap is only the cold-resume path: once the host restarts, nothing can re-mount a preset that no longer exists on disk.

Environment

• dsh 0.1.1-rc.2 (npm global install), profile web
• Node v24.19.0, Windows 11 (10.0.26100)

Minimal reproduction

1. Author a user preset: ~/.dsh/.agent-presets/router-standard/agent.cordis.yml (a copy of any shipped preset works).
2. Create a session under it, run at least one turn, close/stop the session.
3. Delete or rename ~/.dsh/.agent-presets/router-standard/, or modify it so that id leaves the roster.
4. Restart the host; open the session (or click the Mode selector, which lazily resumes).

Actual (verbatim from the affected host):

模型操作失败：internal: resume failed for session "session-2c50143f-cf3e-4236-a0ee-d462bb2e605e": Error: agent-presets: preset "router-standard" not found (available: standard, code, minimal, cordis, liangshen)

(liangshen is an unrelated user preset already on that host; the other four are the shipped built-ins.) The same message arrives in the RPC error.message:

{
  "ok": false,
  "error": {
    "code": "internal",
    "message": "resume failed for session \"session-2c50143f-cf3e-4236-a0ee-d462bb2e605e\": Error: agent-presets: preset \"router-standard\" not found (available: standard, code, minimal, cordis, liangshen)",
    "details": {}
  }
}

The UI surfaces only that generic 模型操作失败 toast, and every session recorded under the missing id strands permanently. In one real deployment here, 20 of 78 persisted sessions stranded behind a single deleted id.

Expected: either the session still resumes (documented fallback), or the failure is a structured, actionable error with a recovery path - not an opaque internal.

Root cause

Resume funnels through the recorded effective preset (newest agent-preset/selected event, else the header - packages/preset/agent-presets/src/session.ts, resolveSessionPreset) into:

• packages/host/apiproxy/src/api-proxy.ts -> composeAgent(presetId) -> presets.resolve(id) -> throws UnknownPresetError (packages/preset/agent-presets/src/preset.ts),
• which the generic resolver catch wraps into { code: 'internal' } (packages/api/remotes/src/agent-lookup.ts, resume failed for session ...), discarding the structured agent-preset-not-found details ({ agentPreset, available }) that the wire protocol already defines.

Notably, the cold transcript read already degrades gracefully: standingKeyFor failures are swallowed so history stays viewable without the preset. Resume is the only path left failing hard, which makes the inconsistency easy to hit and confusing to diagnose.

A session's preset is deliberately fixed at creation (assertPresetUnchanged), and blank-session switches are recorded as agent-preset/selected log events where the newest wins - i.e. the persistence layer already has everything needed to re-point a session at another composition explicitly.

Suggested directions (pick per taste)

1. Minimal: let the resume path surface agent-preset-not-found instead of internal (the RPC details map already carries { agentPreset, available }). Clients could then offer recovery.
2. Recovery flow: on that error, let the client adopt the session under an existing preset by appending an agent-preset/selected event - same durability mechanism agentPreset.select uses while blank, extended to the stranded case.
3. Documented fallback: resolve missing ids to the deployment default composition under the ghost id, with a warning. A tiny process-level shim proves this is viable end-to-end (below).

Verified workaround (process-level plugin)

A home-patch plugin wrapping the live service instance keeps all 20 stranded sessions resumable with no directories recreated:

export const inject = ['agentPresets']
export function apply(ctx) {
  const presets = ctx.agentPresets
  const original = presets.resolve.bind(presets)
  presets.resolve = async (id) => {
    try { return await original(id) }
    catch (error) {
      if (!(error instanceof Error) || typeof error.presetId !== 'string') throw error
      const standIn = await original(undefined) // deployment default
      return { ...standIn, id }                 // ghost id keeps scope isolation
    }
  }
}

All consumers (create/resume/fork/cold read via resolveMountable/standingKeyFor) degrade together because they funnel through resolve() / this.resolve().

Prior art checked

Searched Discussions & Issues for preset not found, resume failed; no duplicate found. Closest: #3018 (default-preset change not applying to a reused blank session), same lifecycle area, different symptom.

[PerryLink]

Your root-cause analysis holds, and it is still unfixed on master (c291e79), with one detail to update.

Current state (verified in source):

• Cold resume still resolves the recorded preset id and throws when it is missing:
  packages/preset/agent-presets/src/index.ts:373
  agent-presets: preset "X" not found (available: ...)
• That error is still wrapped by the generic fallback into internal, dropping the structured details:
  packages/api/session-controller/src/agent.ts:214-219
  new RemoteError('gateway/internal', "resume failed for session ...: " + String(error), {})
  (the old api/remotes/agent-lookup path was folded into the Session Controller refactor d26acfa; the "wrapped as internal" behavior was preserved.)

So "delete the mode → sessions strand permanently" still holds. Recovery options today (pick one):

1. Recreate the preset directory: put an agent.cordis.yml back into ~/.dsh/.agent-presets/<original id>/ (copying any built-in preset works, as long as the id matches), restart, and the recorded sessions recover;
2. Use the plugin shim you already validated in this thread: wrap agentPresets.resolve so unknown ids fall back to the default composition while keeping the ghost id — your 20 stranded sessions recover without recreating directories;
3. Prevention: rename/copy-keep a preset before deleting it, or rebind sessions to another preset first.

Upstream fix direction (as per your post): the resume path should surface the structured agent-preset-not-found({agentPreset, available}) instead of internal, and the client should offer a "rebind to an existing preset" recovery entry (the persistence layer already has the agent-preset/selected event mechanism). Cold history reads already degrade gracefully; only resume hard-fails — that inconsistency is real.

[BigUncle]

中文

对上帖里的垫片片段，两点实测结论。均针对已安装的 harness、c291e7961，非推断。若有人拿那段片段当 workaround，两条都重要。

1. 片段里的谓词现在已经匹配不到任何东西

packages/typert/protocol/src/remote-error.ts:12-31 把 code 与 details 作为自有属性构造，并设 name = 'RemoteError'；没有 presetId / available 字段。实测 new RemoteError('agent-preset/not-found', ..., { agentPreset: 'liangshen', available: [...] })：

constructor.name : 'RemoteError'
error.code       : 'agent-preset/not-found'
error.details    : { agentPreset: 'liangshen', available: [...] }
error.presetId   : undefined
error.available  : undefined

于是 typeof error.presetId !== 'string' 成立，片段在每次未命中时都直接 rethrow——从不降级。该类文档已明说这条规则：判别一律按 code，绝不用 instanceof。一个同时读两代的结构化判定（先 code，再它取代的那个类所携带的自有 presetId/available），可让两个方向的升级都继续工作。

2. 只包 resolve() 覆盖不到 invalid 那条路——而那正是升级实际产生的形状

会话记录的预设若组合装不上，报的是 agent-preset/invalid 而非 not-found，且完全不经过 resolve()：

• resolveMountable() 拒绝发现阶段就已读坏的行走 — packages/preset/agent-presets/src/index.ts:390-398；
• 发现阶段接受、但被 Loader 拒绝的组合从更深处抛出：packages/preset/agent-presets/src/mount.ts:425-427 构造 `${mountDetail(error)} (${preset.path})` 并抛 agent-preset/invalid，由 ensureStanding() 在 index.ts:802 浮出。

第二种正是当前的 @deepseek-ai/dsh-persona 改名（text → 必填 prefix）：改名之前创作的预设以 $.prefix missing required value (at prefix) (<preset path>/agent.cordis.yml) 失败，恢复时落进同一个 gateway/internal 兜底（packages/api/session-controller/src/agent.ts:216-217），搁浅方式完全一致。因此只包 resolve() 的垫片，会让这一整类搁浅会话继续搁浅——同一种失败，不同的 code。

包住挂载 seam 能修好它；但对坏预设去包 resolve() 不行：read/copy/remove 都经 resolve() 取行（index.ts:524、:563、:600），在此处换成替补，会让 remove() 去删替补的目录而不是那个坏预设的，从而消灭"删掉它再重建"这条出路。救援属于"为挂载而解析"的 seam，而 resolve() 仍应返回真实行。

补一条机制说明，给其他想包裹运行中服务实例的人：实例级方法替换确实能穿过服务代理。ctx.agentPresets 是 cordis 的 traceable proxy（@deepseek-ai/cordis lib/index.js:123-157）；写入会落到真实实例上，成为遮蔽原型方法的自有属性，内部 this.x() 调用同样命中包装。已对一个真实 Service 子类做端到端验证。推论在卸载侧：用赋值还原会永久留下一个自有属性遮蔽原型方法，因此实例原本没有自有属性时，还原意味着删掉它。

对上游客栈的净结论：上帖列表第 1 点（透传 agent-preset/not-found 而非 internal）必要但不充分——agent-preset/invalid 需要同等对待，否则升级诱发的那种变体仍会产出同样的笼统 gateway/internal。

---

English

Two measured findings on the shim in the original post, verified against the installed harness on c291e7961 rather than inferred. Both matter if anyone reaches for that snippet as the workaround.

1. The predicate in the snippet no longer matches anything

packages/typert/protocol/src/remote-error.ts:12-31 builds code and details as own properties and sets name = 'RemoteError'; there is no presetId / available field. Measured on new RemoteError('agent-preset/not-found', ..., { agentPreset: 'liangshen', available: [...] }):

constructor.name : 'RemoteError'
error.code       : 'agent-preset/not-found'
error.details    : { agentPreset: 'liangshen', available: [...] }
error.presetId   : undefined
error.available  : undefined

so typeof error.presetId !== 'string' holds and the snippet rethrows on every miss — it never falls back. The class doc states the rule outright: discrimination is always by code, never by instanceof. A structural test that reads both generations (code first, then the own presetId/available the replaced class carried) keeps working across an upgrade in either direction.

2. resolve() alone cannot cover the invalid path — which is the shape upgrades actually produce

A session recorded under a preset whose composition will not install reports agent-preset/invalid, not not-found, and it never passes through resolve():

• resolveMountable() refuses a row discovery already read as broken — packages/preset/agent-presets/src/index.ts:390-398;
• a composition discovery accepted but the Loader rejects throws from deeper: packages/preset/agent-presets/src/mount.ts:425-427 builds `${mountDetail(error)} (${preset.path})` and throws agent-preset/invalid, surfaced by ensureStanding() at index.ts:802.

That second one is the current @deepseek-ai/dsh-persona rename (text → required prefix): a preset authored before the rename fails with $.prefix missing required value (at prefix) (<preset path>/agent.cordis.yml), resumes into the same gateway/internal fallback (packages/api/session-controller/src/agent.ts:216-217), and strands identically. So a shim wrapping resolve() alone leaves that entire class of stranded sessions stranded — the same failure with a different code.

Wrapping the mount seams fixes it, but wrapping resolve() for the broken case does not: read/copy/remove all resolve their rows through resolve() (index.ts:524, :563, :600), so substituting a stand-in there makes remove() delete the stand-in's directory instead of the broken preset's, which removes "delete it and recreate it" as a way out. The rescue belongs at the resolving-for-mounting seams, with resolve() still returning the real row.

One mechanism note, for anyone else wrapping the live service instance: instance-level method replacement does survive the service proxy. ctx.agentPresets is cordis's traceable proxy (@deepseek-ai/cordis lib/index.js:123-157); writing a method to it lands on the real instance as an own property that shadows the prototype method, and internal this.x() calls hit the wrapper too. Verified end-to-end against a real Service subclass. The corollary is on unload: restoring by assigning the original leaves a permanent own property shadowing the prototype method, so removal means deleting the own property when the instance had none.

Net for the upstream fix: point 1 in the original list (surface agent-preset/not-found instead of internal) is necessary but not sufficient — agent-preset/invalid needs the same treatment, or the upgrade-induced variant keeps producing the same opaque gateway/internal.

[PerryLink]

Both corrections accepted — you're right on both, and I withdraw my earlier
endorsement of the shim as posted. Re-verified against the same checkout (c291e79):

1. The predicate can't match. RemoteError now carries code and details as
   own properties and sets name = 'RemoteError'; there is no presetId /
   available field (packages/typert/protocol/src/remote-error.ts:12-31), and the
   class doc says discrimination is by code, never by instanceof (line 10).
   So typeof error.presetId !== 'string' holds on every miss and the shim
   rethrows — it never falls back. Anyone holding that snippet as a workaround
   should treat it as a no-op.

2. resolve() wrapping is the wrong seam, for exactly the reasons you give.
   Broken rows still resolve successfully (packages/preset/agent-presets/src/
   index.ts:356-360), and the agent-preset/invalid rejections come from the
   mountable seams instead: resolveMountable() (index.ts:390-400) and the
   Loader-rejected composition throw (mount.ts:425-431), plus the unreadable-
   stamp case (index.ts:801-805) — all of which collapse into the same
   gateway/internal fallback (packages/api/session-controller/src/agent.ts:214-220).
   One nuance to your "完全不经过 resolve()": the row does pass through
   resolve() first (resolveMountable calls this.resolve(id) at index.ts:391)
   — it just doesn't fail there, so a resolve()-only wrapper can't intercept
   either branch. And since read/copy/remove all resolve their rows through
   resolve() (index.ts:523-524, :563, :600), a stand-in row there would indeed
   make remove() delete the stand-in's directory. The rescue belongs at the
   resolving-for-mounting seam, with resolve() still returning the real row.

Also verified: your proxy mechanism note — the cordis traceable proxy's set
trap writes own properties onto the real instance (vendor/cordis/lib/
index.js:123-157), so instance-level wrapping works and unload must delete
the own property rather than reassign it. And the persona example: the row
schema now requires prefix (packages/preset/persona/src/index.ts:49-54),
so presets authored before the text→prefix rename do fail as
agent-preset/invalid.

Net effect on the upstream direction I listed: surfacing agent-preset/not-found
alone is not sufficient — agent-preset/invalid needs the same structured
treatment, or the upgrade-induced variant keeps producing the same opaque
gateway/internal. Thanks for the measured corrections.

---

中文要点：两条更正均成立，已按同一 checkout（c291e79）复核，并撤回我之前对原
垫片的背书。RemoteError 现只有 code/details 两个自有字段（remote-error.ts:12-31），
谓词永不命中，垫片每次未命中都直接 rethrow。invalid 路径走的是
resolveMountable（index.ts:390-400）与 mount.ts:425-431 的挂载 seam，不经
resolve() 失败（行会先经 resolve() 成功返回）；read/copy/remove 又都依赖
resolve() 取真实行（:523-524、:563、:600），所以救援应包在「为挂载而解析」的
seam 上。上游方向相应修正：agent-preset/not-found 与 agent-preset/invalid 需要
同等结构化透传。