[Bug] DeepSeek adapter emits inline role: "system" tool_addition blocks → HTTP 400 that permanently breaks the session

[FBIwar]

Summary

When the tool set changes inside a live session (install/update/remove a plugin), the
agent loop appends a developer/message carrying tool-addition / tool-removal
blocks. The DeepSeek adapter converts those blocks into an inline system message:

{"role":"system","content":[{"type":"tool_addition","tool":{"type":"tool_reference","name":"ops_bash"}}]}

The endpoint rejects the whole request:

messages.14: `tool_addition` blocks can only be in `system` messages (request_id: f118cf00-…)

Because the record is durable, every subsequent turn of that session fails the same
way — retry, restart and model switch do not help. On this machine 6 of 30 session
logs are poisoned (20 %), all of them triggered by installing/updating a plugin while
a session was open.

Code

dsh/node_modules/@deepseek-ai/dsh-agent-loop/lib/index.js:1241-1259

if (baseline !== void 0 && headerSeq !== void 0) {
    const previousNames = new Set(baseline.tools?.map((tool) => tool.name));
    const currentNames = new Set(tools.map((tool) => tool.name));
    const additions = …; const removals = …;
    if (additions.length > 0 || removals.length > 0) session.append("developer/message", {
        …position,
        message: createDeveloperMessage({ source: { kind: "tool-registry" }, content: […additions, …removals] }),
        …additions.length > 0 ? { headerSeq } : {}
    }, { surfaceOp: "append" });
}

No route/model capability check: the record is written for any model, including ones
that cannot express mid-conversation tool changes.

dsh/node_modules/@deepseek-ai/dsh-llm-deepseek/lib/index.js

• :559-560 — MESSAGES_TOOL_CHANGES_BETA = "mid-conversation-tool-changes-2026-07-01"
• :1638-1651 — tool-addition / tool-removal blocks are serialized
• :1655-1658 — pushed as { role: "system", content: […] } into the message list
• :2216 — the anthropic-beta header is added only when such blocks are present

dsh/node_modules/@deepseek-ai/dsh-llm/lib/index.js:786-800 already contains the
opposite behaviour: when toolUpdate is undefined the projection returns
withoutDeveloperMessages(messages), i.e. these blocks are stripped and the request
succeeds. The adapter advertises toolUpdate: "addition-only" for every built-in
model (:47-48), and there is no configuration surface that can clear it
(dsh-llm-deepseek-account rejects models, only modelOverrides exist and they
merge instead of delete).

Reproduction

1. Open a session on deepseek-flash.
2. While it is open, install any plugin that registers tools (e.g. dsh-ops from the
   market).
3. Send a message in that session.
4. → 400 … tool_addition blocks can only be in system messages; the same error is
   returned for every later turn, in this and any future app run.

Session log evidence (v4 JSONL, ~/.dsh/sessions/<workspace>/<id>/session.v4.jsonl.zstd):

seq 395  developer/message  content: [{type:"tool-addition",toolName:"acp_read_original_image"},
                                     {type:"tool-removal",toolName:"read_original_image"}]
         → request 0323a457… 11:02:40.724 failed
seq 414  developer/message  content: [{type:"tool-addition",toolName:"ops_bash"},
                                     {type:"tool-addition",toolName:"ops_discover_tools"},
                                     {type:"tool-addition",toolName:"ops_read_files"}]
         → request 288d8a50… 11:05:58.291 failed

Expected

• The request succeeds; tool declarations are simply re-sent (or the blocks are omitted
  when the route cannot express a mid-conversation change).
• At minimum, a failure must not leave a durable record that poisons all future turns.

Suggested fixes

1. Gate the append in agent-loop on adapter capability
   (preparedCall?.toolUpdate !== undefined), or
2. In dsh-llm-deepseek, when the model/route does not support the beta, drop
   tool-addition/tool-removal blocks before serialization (reuse the
   projectToolUpdates fallback), instead of turning them into inline system messages.
3. Make the failure recoverable: if a request fails on these blocks, mark the record
   ignorable so later turns project it away.

Local workaround used

Offline log surgery: for each affected developer/message, the tool-change blocks were
removed and the paired headerSeq dropped (the v4 admission rules require headerSeq
to be absent when no tool-addition block remains), re-compressed frame-by-frame with
checksums. seq stays dense and other rows stay byte-identical, so the session loads
and appends normally afterwards. Script: fix_session_toolchange.mjs in the workspace
that produced this report.

[Audit465]

Independent reproduction on 0.1.0-rc.6 / Windows 11 x64, deepseek-account →
https://api.deepseek.com/anthropic, deepseek-flash, reasoningEffort high. Same failure,
plus two data points I did not see above.

1. It is not escapable in-app — not even /compact. From the turn/end rows of the
poisoned log (session.v4.jsonl.zstd):

turn 81  12:37:54Z  request c267c758-2bb7-4a54-aae5-4bbb7c2cb0d7
turn 82  12:38:40Z  request 0d1374ef-9ece-4164-b5af-c12c69c095fc
turn 83  12:39:45Z  request 4cbd4f8c-afeb-47ff-a130-a8097649af71   ← the user issued /compact
turn 84  12:44:18Z  request b054b644-6d84-4ec3-bccb-c6790b2b09cd   ← after a full app restart

So compaction re-sends the same history and dies too, and the restart adds nothing. The
trigger was a plugin-market update (@furongjun1999/dsh-memory 0.9.8 → 0.9.9) while that
session was open — consistent with your "6 of 30 logs, all plugin installs/updates".
The session also contained a developer/message that removed 17 mnemon_* tools and one
that added 23 acp_* tools, and it survived 70 turns — so it is specifically the request
that first carries an addition under addition-only that goes down, not every such row
(I have 4 other sessions with developer/message rows that still work fine).

2. The log-surgery workaround did not hold here. After rewriting all 13
developer/message rows (tool-additions folded into one text block, headerSeq
dropped, seq verified dense, re-compressed with zlib.zstdCompressSync), the log file is
valid and the session loads — but its sidebar entry is gone. The projection cache
(~/.dsh/storages/session_projcache/sessions/<id>.json) is keyed to the previous bytes and
DSH does not rebuild it for a log modified out of band, so the session is not reachable
from the UI any more. I ended up restoring the original log (11,653,197 bytes) and
abandoning the conversation, dumping the transcript manually. Worth flagging so people
don't assume surgery is a recovery path — it is at best a way to read the log.

3. Related thread: #9911 covers the 422 variant for tool_removal under
toolUpdate: in-history. Same class, other end.

+1 for gating the session.append on adapter capability, and for dropping the blocks
before serialization (reuse the withoutDeveloperMessages() fallback) instead of wrapping
them into an inline system message the endpoint refuses.