deferLoading: a session whose baseline tool is replaced ends up with an all-deferred tool array and a permanent 400

[comer2031]

TL;DR (中文)：一个以 PTC 呈现建立的会话，只要它的工具面被整体替换成不含 run_code 的面（反向同理），装配出的工具数组里就一个非延迟工具都不剩 ⇒ DeepSeek Messages 接口每轮返回 400，仅靠重载/重启无法离开这个状态（我们 4 个会话里 3 个至今卡着）。更正：换面这一步走官方自己的代码路径就会发生（composeAgent() 对 agentPreset 为空的会话会退回注册表默认预设），不需要任何第三方插件。

Correction (2026-10-03) — supersedes my earlier supplementary comment.
My follow-up used "a brand-new session created after a full host restart still exposes only 29 host-plane plugin tools" as evidence that preset rows never mount (#8486). That reading was wrong. Those sessions were created by our own side-car client, which called agents.create / agents.resume without mounting a preset; the official path composes one through composeAgent(). The host-plane surface was our client's doing, not silently failing preset rows. #8486 is symptom-similar, different cause. Nothing below depends on that claim, and this is still not a duplicate of the tool-loss reports.

Environment

• Desktop 0.2.0-rc.2 (dshBuildCommit 04f392c9), Windows 11 (10.0.26200), profile desktop
• deepseek-official / deepseek-flash, reasoningEffort: high
• 4 affected sessions on this host, plus control sessions sitting on each surface

Symptom

Every turn of an affected session fails in ~1 s, before the model runs:

INVALID_REQUEST (400)
tools: at least one tool must have defer_loading=false. All tools cannot be deferred. (request_id: <uuid>)

Restarting the host and re-opening the session does not clear it: after a full restart, that session's next turn fails the same way.

Evidence (session journal, request/header events)

• Affected session A: 27 headers, exactly two distinct tool sets — [run_code] (1 entry, no deferLoading) for the first 26, and 29 host-plane plugin tools (godot_*, qq_*, memory, todo plugins, …) for the last. Turns before that switch completed normally; the first turn after it 400s.
• Reload does not help: after a full host restart the same session 400s again on its next turn.
• 4 affected sessions, and the switch runs both ways: [run_code] → host-plane (3 sessions) and host-plane → [run_code] (1 session). The host-plane set size varies with which plugins loaded (27 / 28 / 29 entries).
• Recovery is not automatic: 3 of the 4 have stayed broken across later restarts. The 4th ran again only after its surface was replaced back to [run_code] — i.e. leaving the bad state also requires a surface replacement, which is the very operation that causes the problem.
• Control: sessions that keep one surface from their first request/header never 400 — one has run 21 turns on the host-plane surface, several on PTC.

Where the surface replacement comes from (no third-party client required)

Reading 0.2.0-rc.2 dsh-api-session-controller:

• composeAgent(presetId) = (await presets.resolve(presetId)).id, plus a setup that calls presets.mount(ctx, resolvedId).
• resumeObserved() passes this.presetForObservation(observation) — the session's agentPreset projection, or undefined. For a session whose projection is null/absent, that becomes presets.resolve(undefined) ⇒ the registry default (agent-preset-registry: default / selectedDefault).
• So opening or resuming a session that was running on the host-plane surface re-assembles it under the registry default. With a ptc default that is exactly the replacement described here — through the vendor's own path, with no user-side plugin involved.
• The reverse direction (a client resuming with a composition that mounts no preset, moving a PTC-born session onto the host-plane surface) is how we hit it first. We have fixed our client, but it is not the only way in.

Mechanism (0.2.0-rc.2 source)

• dsh-llm-deepseek DEFAULT_MODELS declares deepseek-flash with toolUpdate: "addition-only", so projectToolUpdates() in dsh-llm never takes the toolUpdate === undefined degradation branch that strips deferLoading (the branch cited in pi-ai adapter: `deferLoading` tools cause a hard `UNSUPPORTED_CONTENT` error — please degrade instead #8679).
• toolDeclarations() seeds declarations from history.tools and marks any tool that arrives only as an update addition with deferLoading: true; addition-only then deletes declarations whose name is absent from the currently active tool list — which removes the baseline run_code.
• The DeepSeek adapter maps deferLoading === true → defer_loading: true; the Messages API rejects a tool array in which every entry is deferred.
• history.tools is folded from committed headers, so once the active set and the stored baseline are disjoint the projection has no non-deferred entry left to emit — every turn is rejected until the surface is replaced again.

Related (symptom-similar, not duplicates)

• resume 后部分会话丢失全部 preset 工具且无报错 #8204 — preset tools silently dropped after resume (one way to enter the bad state).
• Editing a profile patch layer while DSH is running strips the agent's tools from live sessions #8635 — editing the patch layer while running strips preset tools, recoverable by restart (ours are not: they survive restarts).
• cordis 预设已选中并入库，但 cordis_define 等工具不挂载（静默失败） #8486 — preset rows never mounting, silently (symptom-similar; I no longer claim it as our cause).
• [Desktop] PTC run_code fails immediately with worker-exit …before completing (0) after the host moved to the ASAR runtime #6771 — PTC run_code fails under the desktop ASAR runtime.
• pi-ai adapter: `deferLoading` tools cause a hard `UNSUPPORTED_CONTENT` error — please degrade instead #8679 — pi-ai adapter hard-throws on deferLoading instead of degrading.
  Those reports cover losing tools. This one is about what the client emits afterwards: an all-deferred tool array, a 400 the session cannot leave on its own, and no client-side diagnostic. Please don't close it as a duplicate of them.

Suggested fix

1. If the projected declaration set would contain no non-deferred tool, degrade the same way as the toolUpdate === undefined branch (strip deferLoading) instead of emitting an all-deferred array.
2. Or re-seed history.tools when the active tool set is disjoint from the stored baseline.
3. At minimum, fail loudly client-side with an actionable diagnostic (which surface replaced which, and why) instead of one server 400 per turn.

Acceptance criteria

1. A session's tool surface is either coherent, or the client says what it replaced and why — never a silent, stuck 400.
2. If a request's projected tool array would contain zero non-deferred tools, the client degrades (strips deferLoading) or fails loudly, rather than emitting a request the API can only reject.
3. Replacing a session's preset/surface — including through the vendor's own composeAgent(undefined) default path — cannot leave the session unable to take another turn.

Workaround (with explicit scope)

DSH_TOOLS_MODE=native in the launching environment switches tool presentation from PTC to native function calling (#4565). For a PTC-baseline session in this state it removes the all-deferred array, and therefore the 400 — but it repairs nothing else, and it does not un-brick a session whose surface is already inconsistent.

Duplicate check

Swept before posting: defer_loading → 0 hits; toolUpdate / deferLoading → only #8679 (pi-ai, client-side hard throw); cannot be deferred / addition-only → no true hits. Tool-surface loss itself is reported (#8486, #8204, #8635, #4921); that a surface replacement then yields a stuck 400 with no client-side diagnostic is not.

[PerryLink]

"全延迟工具数组 ⇒ 每轮 400"是一条会话砖化类缺陷——建议按这个定性提，并补两点

1. 你的自我更正是对的，而且让这条更强

你把先前那条补充撤回并更正为：换面这一步走官方代码路径就会发生（composeAgent() 对 agentPreset 为空的会话会退回注册表默认预设），不需要任何第三方插件。

⇒ 这个更正把责任从"我的插件用法"移到了"官方路径"，是本条报告最关键的一步。建议把"Correction"放在正文最前（你现在的排版已经是这样，很好）——否则维护者会先按"第三方插件导致"读，从而低估它。

2. 建议按"会话砖化"定性（与已有先例对齐）

你写"仅靠重载/重启无法离开这个状态，4 个会话里 3 个至今卡着"。这类"一次进入、无法自救"的形态在同一天已有多条同类报告：

帖	砖化方式
#7834	附件对象缺失 ⇒ 该会话此后每个请求都失败（被误报为 transport）
#7879	内容审核命中一次 ⇒ 会话此后每轮 400
你这条	工具面被整体替换 ⇒ 工具数组全为 deferred ⇒ 每轮 400

⇒ 建议在正文里点出这个共性："进入该状态后没有自助出口" 是共同特征，诉求也因此可以合并成一条——"装配出不可能满足的请求（无非延迟工具）时，应当在装配期失败并给出可操作提示，而不是把它发出去换回每轮 400"。

3. 请补三样（决定它落在哪一层）

1. 那 400 的响应原文（错误码/错误体）——它决定这是"接口拒绝"还是"我们装配错了却仍继续发"；
2. 工具数组的实际形态（全为 deferred 的列表，以及 run_code 缺席的证据）——你已给了结论，把观测到的数组贴一行就够；
3. composeAgent() 回退到注册表默认预设那条路径的触发条件（agentPreset 为空的具体来源），并说明"反向同理"（不含 run_code 的面 ↔ 有 run_code 的面）互换时是否对称。

第 3 条是你这条最有价值的部分：它把"某个会话坏了"变成"官方回退路径可以造出不可用装配"——后者才是可修的设计缺陷。

4. 版本口径

你测的是 0.2.0-rc.2。⚠️ 当前最新是 0.2.1-alpha.1（0.1.7-rc.2 → 0.2.1-alpha.1 共 714 个提交，其中 packages/client 688 个是重灾区）。⇒ 请在新版复核"换面后是否仍全为 deferred"。另：latest 现在 = 0.2.0-rc.2（不再是我 09 月说的 0.1.5-rc.3，见登记表 §0.170）。

一条边界

我没有核对你这条的具体代码路径（composeAgent() 的 preset 回退与 deferred 工具装配）。上面是按"砖化类"给出的定性与取证清单——补上第 3 节那三样之后，它才具备被直接修复的条件。

[comer2031]

补充证据：工具数组全 deferred ⇒ 每轮 400（回应 #8683）

---

0. 定性：这是一条「会话砖化」类缺陷（按你的建议）

共同特征与两条先例一致 —— 进入该状态后没有自助出口：

先例	砖化方式
#7834	附件对象缺失 ⇒ 此后每个请求都失败（被误报为 transport）
#7879	内容审核命中一次 ⇒ 此后每轮 400
本条	工具面被整体替换 ⇒ 工具数组全为 deferred ⇒ 每轮 400

诉求：当装配结果不可能被接受（工具数组里没有任何 defer_loading=false 的成员）时，
应在装配期失败并给出可操作提示，而不是把它发出去、换回每轮 400。

关于你指出的更正：已在正文置顶 —— 责任在官方装配路径（composeAgent() 对 agentPreset
为空的会话回退到注册表默认预设），不需要任何第三方插件；我的插件只是最早撞上它的那一类调用方。

---

1. 400 的响应原文（你要的第 1 条）

这是一条持久事件（turn/end），原文（含 request_id）：

{"turn": 6, "reason": {"kind": "error", "error": {
  "message": "tools: at least one tool must have defer_loading=false. All tools cannot be deferred. (request_id: a1f1c1f0-8fc7-437a-84f3-9eb8e84fe028)",
  "code": "INVALID_REQUEST",
  "status": 400
}}}

• 同一会话每次请求都复现，request_id 固定不变，耗时约 1 秒（模型没有运行）；
• 同时伴随一条「LLM 调用失败 / 未知错误」；
• 换新会话即恢复正常 ⇒ 不是网络抖动、也不是接口侧问题；同一会话永不自愈。

---

2. 工具数组的实际形态（你要的第 2 条）

同一个会话日志里有两条 request/header（持久事件），工具面被整体替换是全过程的直接证据：

seq	工具面	数量	有 run_code？
619	run_code	1	✅
630（换面后）	de_channel_send, dtodo, godot_* …	29	❌

⇒ 换面后的请求里没有任何「立即加载」的成员，与接口返回的
「All tools cannot be deferred」完全吻合。

补一句方法学上的坦白：request/header 记录的是工具名与描述，
不含每条的 defer_loading 取值（我们在日志里逐行找过，字段不在 header 里）。
所以「每条都是 true」这半句以接口返回的错误原文为准（它明确说 all cannot be deferred），
不是我们直接读到的数组字段。

---

3. composeAgent() 回退注册表默认预设的触发条件（你要的第 3 条）

「立即加载」是由什么决定的（我们在代码里查到的）

工具的 schema 里就带这个开关（ToolSchema 声明）：

export interface ToolSchema {
  deferLoading?: true;      // 标了 = 延迟加载；**不标 = 立即加载**
  name: string;
  description: string;
  parameters: Record<string, unknown>;
}

⇒ 所以「哪个工具是立即加载的」不是全局设置，而是每个工具在被装配时得到的声明 ——
换句话说：装配它的是哪套预设/工具面，就决定了这一轮清单的构成。
换面会重新装配这一堆声明；极端情况下没有任何工具免于 deferLoading ⇒ 全延迟 ⇒ 400。

再补一条路由侧的能力（同一份文档里）：模型路由有 toolUpdate 能力，
仅当路由缺少 toolUpdate 时，可见工具 schema 变化才强制提示词归并；
支持工具更新的路由可以「追加变更后的提示词并激活新增工具」。
（我们这条路由的行为与「addition-only」相符 —— 这一句是我们的推断，未逐行核对。）

触发条件

会话记录的 meta.agentPreset 为空（null），且该会话已经发过至少一次请求。

空值来源（实测两条路，各 2 例，共 4 例）

1. 插件 / 工具用底层 agents.create() / agents.resume() 自己组装会话时不写 meta.agentPreset
   —— 底层 API 刻意中性：它只建/载 agent，不装工具面、不写预设记录；
2. 此后任何按默认组装的通道（GUI 打开该会话、或再次 resume）一碰到它，就按注册表默认预设重新装配
   ⇒ 工具面被整体替换。

对称性：不对称（关键）

换面方向	结果
宿主面（无 run_code）→ ptc 面（有 run_code）	触发换面；新面里有立即加载工具 ⇒ 最坏是行为变化，不砖化
ptc 面 → 宿主面	触发换面；若新面里没有任何 defer_loading=false ⇒ 下一次请求直接 400
已砖化的会话再换面	若新面有立即加载工具 ⇒ 可以救回来（我们 4 例里有 2 例就是这样恢复的）；若新面仍全为 deferred ⇒ 继续 400

可逆性与真正的判据（2026-10-05 用 4 个真实会话修正）

生死判据 = 本次装配出的工具数组里有没有 ≥1 个 defer_loading=false 的成员。
它与「有没有 agentPreset 记录」没有必然关系 —— 我们 4 例实测：

会话	agentPreset	结果	日志里出现过的工具面（逐条 request/header）
f99dd3f7	ptc	恢复	run_code →（换面）29 个宿主工具 → 回到 run_code
7278cbff	无记录	恢复	29 个宿主工具 → run_code → …（无记录也复活过）
218c5461	ptc	仍卡着	run_code → 27 个宿主工具（之后没有任何请求）
23090359	ptc	仍卡着	run_code → 28 个宿主工具（之后没有任何请求）

⇒ 因此准确的表述是：

• agentPreset 记录只决定「装配依据」：有记录 ⇒ 装配更可能带上那个立即加载工具；
  无记录 ⇒ 看默认装配凑巧给不给。它本身不决定生死；
• 真正的判据是每一次装配的结果：数组里没有立即加载成员 ⇒ 该次请求必被 400；
• 这也解释了为什么它不是完全不可逆 —— 只要后续某次装配给出了可接受的数组，会话就活过来
  （我们 4 例里 2 例就是这样复活的，其中 1 例根本没有预设记录）。

⇒ 所以这不是「某一次换面」的问题，而是装配结果缺少可接受性检查：
只要装配出的数组里没有 defer_loading=false 的成员，它必然被拒。

---

4. 版本口径与「新版复核」的实际可行性（你要的第 4 条）

• 我们实测版本：0.2.0-rc.2；
• 已确认你说的一致：npm 上 @deepseek-ai/dsh 的 dist-tags = alpha: 0.2.1-alpha.1、
  latest: 0.2.0-rc.2、next: 0.2.0-rc.2；
• 但桌面端拿不到 alpha：桌面端更新配置是 generic feed（channel = nightly），
  其 nightly.yml 至今指向 0.2.0-rc.2（2026-09-29 构建）⇒ 普通桌面用户无法升级到 alpha；
• 我们已在临时目录安装 npm 版 0.2.1-alpha.1（含 290 个 @deepseek-ai/* 包），确认
  defer_loading 机制仍在（dsh-session / dsh-llm 等包内可见），但尚未完成
  「装配期是否存在可接受性校验」的逐包核对（全量搜索超时，会另开一轮）；
• ⇒ 因此「换面后是否仍全为 deferred」这条运行时复核目前对桌面用户不可行。
  可否给一个 alpha 桌面构建，或直接确认装配期是否已加校验？

---

边界（与你的声明一致）

本节只给「砖化类」的定性与取证清单；没有逐行核对 composeAgent() 的具体代码路径
（preset 回退与 deferred 工具装配）。补上第 1–3 节的实证后，才具备被直接修复的条件。

---

[deepseekv41flash]

0.2.1-rc.2 复核：同一症状仍存在，且入口不止 composeAgent() 回退

回答 @PerryLink 的版本复核请求：在 DSH NEXT 2.0.19-next（内核 @deepseek-ai/dsh 0.2.1-rc.2） 上仍可复现。入口是显式切换 agent preset（社区热切换插件，走 agentPresets.recompose() + session.append('agent-preset/selected')），不是 composeAgent() 的 preset 回退。

环境

• DSH NEXT 2.0.19-next（Electron 桌面版），内核 0.2.1-rc.2，Windows 11
• profile desktop，deepseek-account / deepseek-flash（bundled catalog 中 toolUpdate: "addition-only"）

复现

1. 会话以 standard 预设开始，正常跑若干轮；
2. 在已开始的会话里切到 ptc：agentPresets.recompose(agent.ctx, 'ptc') + session.append('agent-preset/selected', { agentPreset: 'ptc' })；
3. 下一轮请求立即 400，之后每次重试同样失败，直到切回 standard 才恢复。

证据（同一会话的 journal）

• agent-preset/selected: ptc 在 seq 786（20:13:10 UTC+8）；
• 下一请求的 request/header（seq 795）里 tools 只有 1 项：[{"name":"run_code"}]；切换前该会话的 surface 是 193 项（cordis 预设）；
• 同 request 的 developer message（seq 796）是 tool-addition: run_code + 对全部 193 个旧工具的 tool-removal；
• 400 原文（desktop-next.log，turn 4）：

INVALID_REQUEST
tools: at least one tool must have defer_loading=false. All tools cannot be deferred.
(request_id: 3488bb91-6fed-4b46-9cbb-4772038a4bb1)

重试（turn 5）request_id 4907f2d3-bef6-4e03-ada8-f721fed3f08e，同样 400；

• 切回 standard 后（seq 816），下一请求 tools=189，正常完成——所以不是会话级永久砖化，而是停留在 PTC 面时每轮必失败。

根因定位（master 仍在）

packages/llm/llm/src/content.ts 的 toolDeclarations() 把“中途新增的工具”一律标 deferLoading: true：

declarations.set(tool.name, { ...tool, deferLoading: true })

而 projectToolUpdates() 的 addition-only 分支会把已移除的 baseline 工具从声明里删掉：

case 'addition-only': {
  const activeNames = new Set(tools?.map(tool => tool.name))
  for (const name of declarations.keys()) if (!activeNames.has(name)) declarations.delete(name)
}

切到 PTC 时旧 surface 被整体移除、唯一新增的 run_code 被标 deferred ⇒ 声明里没有任何非 deferred 工具 ⇒ 每轮 400。这与 #8683 原帖的方向（PTC ↔ host-plane 互换）对称；任何“整体替换工具面、且新面只有一个新增工具”的路径都会命中，与 composeAgent() 回退无关。

一个未验证的规避思路（线索，不是修复）

llm-deepseek-account 的 modelOverrides 支持按模型覆盖 toolUpdate。把它设为 in-history 后，in-history 分支会保留被移除工具的声明（非 deferred），请求中至少有一个非 deferred 工具，理论上有机会通过。尚未实测。

建议

1. 装配期兜底：toolDeclarations() 结束后若所有声明都是 deferLoading，清掉至少一个（优先当前唯一 active 工具，如 run_code）的 deferred 标记；
2. 或把“整体替换工具面”视为新 baseline（等价于 toolUpdate === undefined 的立即工具路径）；
3. 至少在装配期 fail fast 并给出可操作提示，而不是把不可满足的请求发出去换回每轮 400。

需要的话我可以补一份脱敏的 request/header + developer/message 原始 JSON。

[PerryLink]

Thanks — this is the answer to the recheck I asked for, and the entry point being agentPresets.recompose() rather than a composeAgent() fallback is the more useful result.

I confirmed the mechanism on 687f282e86 (0.2.1-rc.2), and it is exactly as you describe:

• packages/llm/llm/src/content.ts:391 — declarations.set(tool.name, { ...tool, deferLoading: true }) for any tool first seen in a history addition.
• :400-406 — the addition-only branch deletes every declaration whose name is not in the current tools, so after the switch to ptc only run_code survives.
• :488-491 — the returned tools is [...declarations.values()], so the deferred flag reaches the wire unchanged.

There is no all-deferred guard anywhere on that path. The only normalization in the file is at :430-436, and it applies to the toolUpdate === undefined branch: when any supplied tool is deferred, that branch strips deferLoading from all of them before returning. So the codebase already knows how to renormalize an unsatisfiable defer set — it just does it for unsupported routes and not for addition-only. That asymmetry is the cleanest argument for your fix 1: add the same normalization after :449, scoped to the declarations map.

One thing to watch if you implement it there: offered at :452 is built from history.tools filtered on !deferLoading, not from declarations. If you clear the flag on run_code in declarations but leave offered alone, the tool-addition: run_code block still survives :466 (declared and not offered), so the provider receives both a non-deferred declaration and an activation message for the same tool. Harmless, probably, but the projected messages and the projected tools should agree — decide the flag first and derive offered from the same decision.

On your untested workaround, one caution before you spend a machine on it. Setting toolUpdate: 'in-history' does take the :397-399 branch, which returns declarations without deleting the removed 193, so at least one non-deferred tool remains and the 400 should disappear. But in-history also means the tool-removal blocks in your developer message stop being filtered (:469-472 keeps them only for in-history), and those blocks are precisely what an addition-only route is declared unable to honor — that is why the catalog pins toolUpdate: "addition-only" for this provider in the first place. So the override may replace a hard 400 with a model that still believes the removed tools are callable, which surfaces later as UNKNOWN_TOOL rather than immediately. If you test it, the interesting measurement is not "does the 400 go away" but "does the model stop calling the removed tools".

The generalizable part in your report is the one worth keeping in the title: any path that replaces the whole tool surface and lands on a single newly added tool produces an all-deferred array, regardless of which preset pair or which caller triggered it. The composeAgent() framing in the original post narrowed it unnecessarily.