Custom agent presets in $DSH_HOME/.agent-presets/ are no longer registered after upgrading from 0.1.5-rc.1 to 0.1.7-alpha.2

[sunweicai9131-create]

中文摘要（给中文读者）

从 0.1.5-rc.1 升级到 0.1.7-alpha.2 后，放在 $DSH_HOME/.agent-presets/ 里的自定义 agent preset 不再被注册，
导致所有使用自定义 preset 的会话能看历史、但不能继续对话（RemoteError: Unknown agent preset: crew）。
已定位到源码层：上游把 preset 机制从「目录」改成了「组合条目」
（@deepseek-ai/dsh-agent-presets 复数 → @deepseek-ai/dsh-agent-preset 单数），
新版安装树里已经没有任何读取 .agent-presets 目录的代码路径。

我的会话数据未受影响（925/925 个日志字节完全一致，152 万条记录全部可解析）。
详见下方英文全文。

---

Custom agent presets in $DSH_HOME/.agent-presets/ are no longer registered after upgrading from 0.1.5-rc.1 to 0.1.7-alpha.2

Channel: GitHub Discussions — this repository disables Issues and names Discussions
as its bug-report channel in CONTRIBUTING.md. Every claim below was measured on a real
machine; anything I did not establish is marked as such.

Summary

After upgrading @deepseek-ai/dsh from 0.1.5-rc.1 to 0.1.7-alpha.2, every
session whose creation header carries a user-defined agentPreset fails to resume:

resume failed for session "session-a7d197a6-9fd5-4f86-8233-2906d66e2ebd":
RemoteError: Unknown agent preset: crew   (gateway/internal)

The conversation history renders correctly, but the session cannot be continued —
sending a message fails and nothing is written.

Three user-defined presets live in $DSH_HOME/.agent-presets/ (crew, qa, walnut).
They are byte-identical to their pre-upgrade state, yet none of them is registered
by 0.1.7-alpha.2.

This is not a data problem. All 925 existing session logs are byte-identical after
the upgrade; the failure is at preset discovery/registration.

Environment

OS	Windows (Windows 11, PowerShell 7.6.1)
Node.js	v24.15.0
package manager	pnpm 10.34.5
before	@deepseek-ai/dsh 0.1.5-rc.1 (working install, presets work)
after	@deepseek-ai/dsh 0.1.7-alpha.2 (fresh, clean install)
install shape	isolated DSH_HOME containing a byte-for-byte copy of the real home; 267 @deepseek-ai/dsh* packages, all at 0.1.7-alpha.2 (verified uniform, so this is not a mixed-version install)

Expected

A user-defined agent preset placed in $DSH_HOME/.agent-presets/<id>/
(the discovery root used by 0.1.5-rc.1, and the location dsh-crew writes to)
keeps working after the upgrade — or the release notes describe the new model and
a migration path exists.

Actual

The preset is not registered at all.

Evidence

1. The old mechanism was directory-based and shipped its own preset files

0.1.5-rc.1 installs @deepseek-ai/dsh-agent-presets (plural), which contains:

node_modules/@deepseek-ai/dsh-agent-presets/presets/
    cordis/agent.cordis.yml
    minimal/agent.cordis.yml
    ptc/agent.cordis.yml
    standard/agent.cordis.yml

On the npm registry, @deepseek-ai/dsh-agent-presets has no 0.1.7-alpha.x version;
its last published version is 0.1.6-alpha.2:

$ npm view @deepseek-ai/dsh-agent-presets versions --json | tail
  "0.1.5-rc.1", "0.1.5-rc.2", "0.1.5-rc.3", "0.1.6-alpha.1", "0.1.6-alpha.2"

2. The new mechanism is a composition entry, not a directory

0.1.7-alpha.2 instead installs @deepseek-ai/dsh-agent-preset (singular) plus
@deepseek-ai/dsh-agent-preset-registry. The whole of
@deepseek-ai/dsh-agent-preset/lib/index.js is 29 lines:

/** Registers child plugin configuration without owning Agents using older revisions. */
var AgentPreset = class {
  ctx;
  config;
  static inject = ["agentPresets"];
  /** Preserve child expressions until their own plugins activate. */
  static [EntryGroup.key] = true;
  static Config = z.object({
    id: z.string().required(),
    name: z.string(),
    description: z.string(),
    order: z.number(),
    plugins: z.array(z.any()).required()
  });
  constructor(ctx, config) { this.ctx = ctx; this.config = config; }
  async *[Service.init]() {
    yield await this.ctx.agentPresets.register(this.config);
  }
};

A preset is now an entry in an ordinary Cordis composition whose plugins are declared
inline. There is no directory scan.

3. No filesystem path in the new build references an agent-presets directory

Searching the entire installed 0.1.7-alpha.2 tree (node_modules/.pnpm, all *.js):

pattern searched	matches
.agent-presets	none
agent-presets/	none
agent-presets	only "agent-presets-invariant" (registry plugin name) and id: "agent-presets" (a client UI section id) — no path

(The old install does contain @deepseek-ai/dsh-agent-presets/presets/..., as shown above.)

So on 0.1.7-alpha.2 there is no code path that reads $DSH_HOME/.agent-presets/.

4. The user data is intact — this is purely discovery

measurement	value
existing session logs before / after the upgrade	925 / 925
unchanged (byte-identical SHA-256)	925
modified / deleted	0 / 0
added	3 files, all new-generation session.v4.jsonl.zstd
zstd frames decoded across all logs	1,153,761 — 0 failures
JSONL records parsed	1,520,285 — 0 failures
distinct top-level record types	40 — all present in the shipped known-event list

A real pre-existing v3 session was successfully migrated and published as a v4 successor,
which is the behaviour the format design promises.

Minimal reproduction

1. On 0.1.5-rc.1, create a user preset in the old format:
   $DSH_HOME/.agent-presets/crew/ containing preset.yml and agent.cordis.yml
   (this is exactly what dsh-crew@0.10.0 writes — see its host/crew.js,
   PRESET_ID = "crew", join(home, ".agent-presets", PRESET_ID)).
2. Create a session that names it (its header records agentPreset: "crew").
3. Upgrade @deepseek-ai/dsh to 0.1.7-alpha.2 in a clean install.
4. Reopen the session.
5. Observe: history renders, then
   RemoteError: Unknown agent preset: crew (gateway/internal); sending a message fails.

Impact

• Every session recorded with a user-defined preset becomes read-only. History is
  visible; the conversation cannot be continued.
• dsh-crew (the plugin that ships the crew/PM workflow) is at 0.10.0, which is the
  latest published version, and it still writes its preset into
  $DSH_HOME/.agent-presets/crew/. Its entire workflow therefore stops working on
  0.1.7-alpha.x.
• The same applies to any third-party preset that follows the documented
  $DSH_HOME/.agent-presets/ layout.

Things I ruled out (so they do not need re-testing)

• Not a session-format regression. 925/925 logs unchanged; 1.5M records parse; a v3
  session migrated to v4 successfully.
• Not a mixed-version install. All 267 @deepseek-ai/dsh* packages are 0.1.7-alpha.2.
• Not a cascade from another broken preset. Moving qa and walnut out of
  .agent-presets (leaving only crew) and restarting still yields
  Unknown agent preset: crew.
• Not browser state. Reproduced in a fresh private/incognito window.
• Not a missing dependency of the crew preset. All 19 @deepseek-ai/* packages
  referenced by its agent.cordis.yml are present in the 0.1.7-alpha.2 install.

Separate, independent issue found at the same time

The same user presets reference @deepseek-ai/dsh-workflow-worker-thread, whose last
published version is 0.1.5-rc.3; it does not exist at 0.1.7-alpha.1/0.1.7-alpha.2.
So even after the discovery problem is fixed, those two presets would fail to mount.
Worth an upgrade note for preset authors: a package referenced by a preset can disappear
between minor lines.

What I could not determine

• Whether the removal of directory-based .agent-presets discovery is intended, and
  if so, what the documented replacement for user-authored presets is.
• I did not find upgrade/migration notes covering this change. If such notes exist, a
  pointer would be welcome.

Request

1. Either keep the $DSH_HOME/.agent-presets/<id>/ discovery working, or
2. Document the new model (a composition entry with inline plugins) and provide a
   migration path/upgrade note, so preset authors can follow — and so existing sessions
   can be resumed again.

Version data used in this report

@deepseek-ai/dsh                        0.1.5-rc.1  ->  0.1.7-alpha.2
@deepseek-ai/dsh-agent-presets          last version 0.1.6-alpha.2   (plural — removed)
@deepseek-ai/dsh-agent-preset           0.1.7-alpha.2                 (singular — new)
@deepseek-ai/dsh-agent-preset-registry  0.1.7-alpha.2
@deepseek-ai/dsh-workflow-worker-thread last version 0.1.5-rc.3       (removed)
dsh-crew                                0.10.0                        (latest published)
@deepseek-ai/dsh-session-format-catalog currentVersion: 4             (unchanged 0.1.7-alpha.1 -> 0.1.7-alpha.2)

---

Related

This appears to be part of a pattern in the 0.1.6/0.1.7 line, where third-party plugins and presets break in ways that surface far from the cause:

• 0.1.7-alpha.1: legacy client service settingsScope silently removed — third-party plugins hang on boot and the failure surfaces as a misleading client-half failed #7445 — 0.1.7-alpha.1: legacy client service settingsScope silently removed — third-party plugins hang on boot and the failure surfaces as a misleading client-half failed
• tool-cordis registers Host inspect providers globally → any second mount of a preset containing it fails (New Session appears to do nothing) #7147 — tool-cordis registers Host inspect providers globally → any second mount of a preset containing it fails (New Session appears to do nothing)
• [Bug] 空白新会话切换 Agent Preset 后，新 preset 的 modelSelectionSettings 型 delegation 工具完全未安装（subagent / list_subagent_models 缺失） #6751 — [Bug] 空白新会话切换 Agent Preset 后，新 preset 的 modelSelectionSettings 型 delegation 工具完全未安装

A single upgrade note about what changed for third-party preset/plugin authors — and a migration path — would help all of them at once.

[PerryLink]

中文摘要：你的定位是对的，机制确实从「目录」变成了「组合条目」。我按你说的两个版本分别核过：dsh-v0.1.5-rc.1 的源码里确实引用了 agent-presets，而 dsh-v0.1.7-alpha.2 上 .agent-presets 只出现在归档笔记里，没有任何源码读它。迁移方向：把每个 preset 重新声明成一行 @deepseek-ai/dsh-agent-preset，并且沿用原来的 id（crew/qa/walnut）—— 会话头部记录的正是这个 id。

---

Your diagnosis holds, and I can pin down both halves of it at the two versions you named.

Before (dsh-v0.1.5-rc.1) the directory was real source. Searching that tag's packages and apps for agent-presets returns source and test files, not only notes - for example apps/cli/package.json, apps/desktop-host/src/index.ts, and several web/cli e2e tests.

At dsh-v0.1.7-alpha.2 no code reads .agent-presets. Every hit at HEAD is under .agents/notes/archived/, i.e. history rather than a reader. Presets are now declared as composition rows, and the shipped ones live in the bundle:

packages/bundle/web-app/package.json:26    "./presets/*.patch.yml": "./presets/*.patch.yml"
:34-37    presets/standard.patch.yml, ptc.patch.yml, minimal.patch.yml, cordis.patch.yml

and a preset row looks like this (packages/bundle/web-app/presets/standard.patch.yml:4-10):

- insert:
    - id: preset-standard
      name: '@deepseek-ai/dsh-agent-preset'
      config:
        id: standard
        order: 1
        plugins:
          - id: persona
            name: '@deepseek-ai/dsh-persona'

So config.id is the preset id the session header refers to, and config.plugins is the entry list that used to live in your directory.

What to do about the sessions that cannot resume. The header recorded agentPreset: crew, and resume resolves that id through the registry - which is why the failure is Unknown agent preset: crew while history still renders. The shortest path is therefore to re-register a preset whose config.id is exactly crew (and qa, walnut): either through the Web editor, or by adding rows to your profile patch. The Web editor writes the same thing - the standard patch's own header says "Edits saved from the Web editor override this row's config.plugins by id from the profile patch."

I have not tested that re-registering the id makes those sessions resumable again; it follows from the id being the lookup key, but treat it as the expected outcome rather than a verified one.

Boundary: verified at dsh-v0.1.5-rc.1 and at HEAD 00102833df = dsh-v0.1.7-alpha.2. I did not run your three presets.