会话中途注册的 MCP 工具会让该会话此后每一轮 400：tool_addition blocks can only be in system messages

[jamesweiym-ops]

Summary

会话进行到中途时，一个 MCP server 连上并把工具补进注册表，DSH 会在该轮写出一条 developer/message（source.kind = "tool-registry"，内容是若干 tool-addition 块）。此后每一轮都要重放这条消息，而 Messages 端点返回 400：

messages.112: `tool_addition` blocks can only be in `system` messages

结果是该会话永久不可用：用户消息正常入库、助手一轮都不回，UI 侧没有任何错误提示，用户只能丢弃会话重新开始。

English: after an MCP server registers tools mid-session, the session is poisoned by the recorded tool-addition message; every later turn is rejected with messages.N: tool_addition blocks can only be in system messages (400, INVALID_REQUEST).

Reproduction

1. 起一个会话，此时某个 MCP server 尚未连上（工具不在注册表里）；
2. 让该 MCP server 在会话进行中连上（例如服务先挂、随后被 launchd/重连拉起），使它的工具在后续某一轮才进入注册表；
3. 这一轮会写出一条 developer/message，source.kind = "tool-registry"，content 为若干 {"type":"tool-addition","toolName":"…"}；
4. 从这一轮起，每次发消息都返回 messages.N: tool_addition blocks can only be in system messages，表现为"发消息没有回复"。

复现性：我本地两次踩到（一次是 29 个工具的中继首次连上，一次是重启后补连），无例外。

Current behavior

同一会话连续三轮 step 1 直接失败，assistant/attempt 的错误逐字如下（code: INVALID_REQUEST, status: 400）：

messages.112: `tool_addition` blocks can only be in `system` messages (request_id: 29e341ef-5a64-43e2-bedf-c5f75086c446)
messages.112: `tool_addition` blocks can only be in `system` messages (request_id: e0527d5e-e0ac-486b-9f1e-acbbc7ad3113)
messages.112: `tool_addition` blocks can only be in `system` messages (request_id: d33a7259-e5e2-4d84-9d2d-f890bf8ce14d)

会话记录（第 12 轮）里唯一新增的记录是工具注册：

seq 1508  system/message        （运行时上下文）
seq 1509  user/message          （用户发「验证」）
seq 1510  request/header        （工具表快照：29 个 mcp__klox__* 工具均在）
seq 1511  developer/message     source.kind = "tool-registry"，29 × {"type":"tool-addition","toolName":"mcp__klox__…"}
seq 1512  assistant/attempt     → 400

第 13、14 轮只多了一条 user/message，没有新的 developer/message，错误依旧且下标相同（messages.112）——说明失败请求被当作历史的一部分反复重放，会话自身无法恢复。

注意该下标是 0 基：线上被拒的是第 113 条消息，其角色不是 system。

Expected behavior

1. 这些请求应当成功：工具变更不应让整轮请求报废；
2. 即使请求失败，也不应让会话进入"永久失败"状态（重放同一段历史必须仍能成功）；
3. 工具变更的编码方式应满足端点约束（端点明确要求 tool_addition 只出现在 system 消息里）。

Environment

项	值
DSH	@deepseek-ai/dsh 0.2.1-rc.2（npm 全局安装，launchd 常驻 dsh --profile web）
OS / Node	macOS Darwin 27.2.0 arm64 / node v24.21.0
provider / model	deepseek-account / deepseek-flash（systemPromptUpdate: "in-history"）
MCP	klox（streamable-http 本地中继，29 个工具，会话进行中才连上）

Additional analysis

按 0.2.1-rc.2 的 @deepseek-ai/dsh-llm-deepseek（lib/index.js）阅读，这条 developer 消息只可能落到末尾的 system 消息里：

• lib/index.js:1625 flushSystemUpdates：仅在 messages.at(-1)?.role === "user" 时追加累积的 system 更新；
• lib/index.js:1638 / :1645：tool-addition / tool-removal 被翻成 {type:"tool_addition", tool:{type:"tool_reference", name}} 并包进 {role:"system", content:[…]}；
• lib/index.js:1685：只在进入 assistant 消息前以及循环结束时 flush；
• lib/index.js:2216：仅当 body.messages 含有 tool_addition/tool_removal 时才加 anthropic-beta: mid-conversation-tool-changes-2026-07-01（常量在 :560）。

但我用同一把 key 直连 https://api.deepseek.com/anthropic/v1/messages（model: deepseek-flash）做对照，凡是"末尾 system 消息 + 若干 tool_addition 块"的形状全部 200，包括：

• 1 个块 / 29 个块；
• 带 / 不带上述 beta 头；
• 带顶层 system 参数，以及 [user, system(text), system(tool_addition)] 相邻；
• 112 条消息的长历史 + 末尾 [user, system(tool_addition)]；
• [user, system(tool_addition), user]、[user, assistant, system, user]。

唯一能复现逐字相同错误的形状，是把块放进非 system 消息：

// messages[0] 是 user，其中掺入一个 tool_addition
{"role":"user","content":[{"type":"text","text":"a"},
  {"type":"tool_addition","tool":{"type":"tool_reference","name":"demo_tool"}}]}
// → 400 messages.0: `tool_addition` blocks can only be in `system` messages

（我已逐一排除 prepareRequestExtensions、dsh-deepseek-llm-api-extensions（只加顶层字段）与 prepareImages（只替换图片引用）会改动 messages。）

因此想请你们确认：除了 serialize()，还有哪条路径会把历史重新投影成 messages，从而可能把 tool-change 块放在非 system 消息里？ 可疑方向：compaction / 标题等旁路请求、dsh-api-session-controller 的重放路径，或端点对"末尾 system 更新"在某些条件下做的内部合并。

Workaround

在 serialize() 之后、prepareRequestExtensions 之前加一层归一化：把任意消息里的 tool_addition / tool_removal 块改写成等价文本（Tool now available: <name> / Tool no longer available: <name>，任何位置都合法），并把改写前的消息角色与块结构写进日志。上述 29 块形状改写后实测 200，会话立即恢复。

建议官方在请求出口做同类防御，或保证重放时丢弃失效的工具变更。

---

本报告由本人 DSH 会话中的 Agent 整理；日志、请求下标（0 基）与上述直连对照均在本机复现。

[jamesweiym-ops]

Update: instrumented the client, the blocks are in a system message

I added a temporary structural log inside the provider adapter, right before the request is sent, recording each wire message's role and block types. For the rejected session the shape is:

[ /* ... 111 messages ... */,
  { "role": "user",   "content": [ /* turn 12 user message */ ] },
  { "role": "system", "content": [ /* 29 x { "type": "tool_addition", "tool": { "type": "tool_reference", "name": "mcp__klox__*" } } */ ] }
]

So the 29 tool_addition blocks are inside a system message, at index 112 — the last message of the request. The client-side encoding matches the documented placement, yet the endpoint answers messages.112: tool_addition blocks can only be in system messages.

Two properties that may matter for a repro, both true of the failing request and neither reproducible synthetically by me:

1. The tool-change message is the final message of the request — nothing follows it.
2. The blocks introduce tools that just appeared at runtime (MCP server registered), so they are not in the request-level tools array, which still comes from the previous header.

What I tried, all HTTP 200 against https://api.deepseek.com/anthropic/v1/messages (deepseek-flash, with and without anthropic-beta: mid-conversation-tool-changes-2026-07-01): a trailing {role:"system"} carrying 1 or 29 tool_addition blocks, referenced tools present in tools or absent (absent → the distinct error references unknown tool 'ghost_tool'), with/without a top-level system, and with 113-message and 112-message histories. The only synthetic shape that produces the identical text is a block inside a user/assistant message — which reports a different index (messages.0), so it is not the shape above.

That points at the endpoint (or at whatever server-side step turns a trailing tool-change message into something it then classifies as non-system) rather than at the request body. I cannot narrow it further from the client side.

Result of the workaround, for the record: rewriting the blocks to plain text blocks before sending makes the very same session work again — every turn after that completes, and the 400s stop entirely.