Mid-conversation tool change places tool_addition blocks in a non-system message -> permanent 400 INVALID_REQUEST

[ljl54188]

Summary

On @deepseek-ai/dsh@0.2.1-rc.2 (npx, Windows, dsh web), a session that uses deepseek-official / deepseek-flash (which declares toolUpdate: "addition-only") starts returning HTTP 400 for every subsequent turn after the tool set changes once mid-conversation:

DeepSeek request failed (400 INVALID_REQUEST): messages.2: `tool_addition` blocks can only be in `system` messages

The failure is not transient: the offending mid-conversation tool change stays in the session history and every later turn is rejected the same way, so the session is permanently unusable. Restarting the harness does not help (the history is on disk).

Environment

• @deepseek-ai/dsh@0.2.1-rc.2, run via npx, dsh web on Windows 11
• provider deepseek-official, model deepseek-flash (contextWindow: 1e6, systemPromptUpdate: "in-history", toolUpdate: "addition-only")
• session was created by a chat plugin (@zaofan/dsh-qqbot), i.e. turns are driven by an external plugin, not by the Web UI; the agent preset is a custom one
• after turn 1, a plugin (billion-context) registers 6 extra tools into the same session: acp_cache, acp_read_original_image, acp_status, compress, decompress, search_context

Timeline from the session event log

session.v4.jsonl.zstd (workspace session dir ~/.dsh/sessions/--...--/<session-id>/) contains, for the failing session:

• turn 1: system/message, then 6 × user/message, request/header (tools start with the preset tools), assistant/message — OK
• turn 2: step/start, 3 × user/message, request/header, then a developer/message:

{"type":"developer/message","seq":29,"headerSeq":28,"surfaceOp":"append",
 "message":{"source":{"kind":"tool-registry"},
   "content":[{"type":"tool-addition","toolName":"acp_cache"},
              {"type":"tool-addition","toolName":"acp_read_original_image"},
              {"type":"tool-addition","toolName":"acp_status"},
              {"type":"tool-addition","toolName":"compress"},
              {"type":"tool-addition","toolName":"decompress"},
              {"type":"tool-addition","toolName":"search_context"}]}}

and immediately assistant/attempt fails, then step/end / turn/end record the same 400.

• turns 3 and 4 (forced by injecting input into the same session): identical error, and no new developer/message and no new request/header — the failure replays the same poisoned history, index messages.2 is stable.

Where the error points

messages.2 is the 0-based index in the request messages array. Direct probes against https://api.deepseek.com/anthropic/messages (anthropic-version: 2023-06-01, anthropic-beta: mid-conversation-tool-changes-2026-07-01, all 6 tool names pre-declared in tools):

body messages	result
[user, assistant, user, {role:"system", content:[tool_addition(tool_reference)×6]}]	200
[user, assistant, {role:"system", …}, user]	200
[user, assistant, {role:"user", content:[text, tool_addition×6]}]	400 — messages.2: tool_addition blocks can only be in system messages (byte-identical to the production error)
tool_addition with tool:{type:"tool_definition", …}	422 unknown variant tool_definition, expected tool_reference
tool_addition referencing a name absent from tools	400 messages.3.content.0: tool_addition references unknown tool 'acp_cache'

So the server side is behaving as intended: an in-array system message carrying tool_addition/tool_reference is accepted (with or without the beta header), while the same block inside a non-system message is rejected at that message's index. The production request therefore had the addition blocks inside a non-system messages[2].

What I could not reproduce

Instantiating the exported DeepSeekAdapter (@deepseek-ai/dsh-llm-deepseek) with a local HTTP sink and reconstructing the history from the event log ([system, user×6, assistant, user×3, developer]) always yields:

{"messages":[
  {"role":"user","content":[ …6 user messages merged… ]},
  {"role":"assistant","content":[…]},
  {"role":"user","content":[ …3 user messages merged… ]},
  {"role":"system","content":[ tool_addition×6 ]}
]}

i.e. the additions end up in a separate system message at index 3, which the API accepts. Feeding the same blocks in wire form (tool_addition) inside a user message is rejected locally with UNSUPPORTED_CONTENT: DeepSeek Messages cannot represent user/tool-result content tool_addition, so the serializer never emits that shape. I also checked that nothing on this install rewrites the request: only dsh-llm-deepseek-api-key registers provider deepseek-official, the only deepseekLlmApiExtensions registrants write the fields dsh_session_log and dsh_plugin_packages, and the profile plugins (chat plugin, compaction plugin) contain no tool_addition handling.

So the corrupted shape appears somewhere I could not identify, between session projection and the bytes on the wire. One asymmetry worth a look: the durable-block guard in dsh-llm-deepseek (lib/index.js, non-developer message branch, ~:1661) only matches the hyphenated durable names tool-addition/tool-removal, so a wire-shaped tool_addition block sitting in a non-developer message would not hit that guard.

Recovery / workaround (for other users hitting this)

• Restarting does not help; the bad event is persisted.
• Switching that session to a model that does not declare toolUpdate (e.g. deepseek-v4-pro) or dropping the session (new chat / clear the binding) gets you out.

Questions

1. Is this a known interaction (toolUpdate: "addition-only" + tools registered after the first turn) or a bug we should dig into further?
2. Is there an expected way for a session to recover from a rejected mid-conversation tool change without discarding the whole history? Right now one bad developer/message bricks the session.

Happy to provide the full session.v4.jsonl event dump, the captured request bodies, and the probe scripts if useful.

[lxw-360]

Second independent occurrence: 0.2.1-rc.2 + QQ chat bridge + billion-context — same 400, plus evidence it is not deterministic

Environment:

• @deepseek-ai/dsh@0.2.1-rc.2, Windows 11 (Desktop carrier)
• turns driven externally by a QQ chat bridge (SnowLuma, MCP tools), agent preset with 148 tools
• billion-context (ACP) tools (acp_cache, compress, …) attached from turn 1 (not registered mid-conversation)

What happened:

• turns 1–8 on deepseek-official / deepseek-flash (high effort, maxTokens 256000): OK
• turn 9: an MCP server hot-loaded 2 new tools; DSH appended a developer/message (source: tool-registry, 2 × tool-addition) and the attempt failed with:

400 INVALID_REQUEST: messages.28: `tool_addition` blocks can only be in `system` messages

(request_id 013e96a4-efdf-4697-b48a-aaed4be3623f; turn/end error; the harness auto-switched the session to a fallback provider afterwards.)

Points that corroborate / extend your findings:

1. Same adapter conclusion: I also read @deepseek-ai/dsh-llm-deepseek — every local serialization path turns the tool-registry developer message into its own role:"system" message (lib/index.js :1638-1658 and :2216), and the durable-block guard at ~:1661 only matches the hyphenated names tool-addition/tool-removal. The adapter cannot emit the broken shape.
2. Not deterministic: two other sessions on the same install performed mid-conversation tool additions 116 and 12 times respectively with zero failures — including ego_*/univer_* tools added at turns 8–9 while the ACP/billion-context tools were already attached. Something in the pipeline mangles the request only under specific conditions; a middle layer interacting with in-history system messages is the obvious suspect.
3. The trigger does not have to be a plugin registering its own tools: in our case the addition came from an MCP server hot-reload (new tools appearing at runtime). Any mid-conversation tool-table change can poison the session.

Recovery matched yours: the session is bricked (the poisoned history persists); opening a new chat was the only fix. The auto-fallback to another provider did restore service, consistent with your deepseek-v4-pro workaround.

Happy to provide the turn-9 session event dump if useful.