[Bug] A stored subagent notice carrying reasoning makes a session permanently unusable on the DeepSeek Messages protocol

[devacc8]

What happens

With the Messages protocol, which became the DeepSeek default in 0.1.6-alpha.1, every request from a session that holds a subagent settlement notice saved before that release fails:

DeepSeek Messages cannot represent user/tool-result content reasoning

The session is then unusable on any DeepSeek model. A non-DeepSeek route works, a new session works, and the UI offers no way back into the broken one.

Why

dsh-subagent stores the settlement notice as a user/message whose content carries the child's closing message blocks. Before 0.1.6-alpha.1 that included the child's reasoning and tool-call blocks. The 0.1.6-alpha.1 note says new notices pass body text only, and that saved notices are unchanged.

dsh-llm-deepseek serializes user and tool-result content through input(), which accepts text and image and calls unsupported() for anything else. One old notice therefore poisons the whole history, and it stays in the log, so the session cannot be recovered from the UI. A user who only switches the model for one turn keeps the broken session.

The chat-completions serializer in the same package flattens text blocks and silently drops the rest, which is why this appeared only once Messages became the default.

What would fix it

Sanitize historical user and tool-result content at serialization time, the way historical tool arguments are already degraded to {} instead of failing the request, or migrate stored notices on load. Failing the request makes the session permanently unusable, which is a heavy outcome for data the user cannot see or edit.

Reproduction

1. On a build before 0.1.6-alpha.1, let a background subagent settle in a session on a DeepSeek model. Its closing message normally contains reasoning, so the notice carries it.
2. Upgrade to 0.1.6-alpha.2.
3. Send any message in that session. Every request fails with the error above.

Verification

Verified on 0.1.6-alpha.2, Node 22, Linux. 15 stored sessions on one machine carried such notices (147 notice events, 140 reasoning blocks and 82 tool-call blocks), and every one of them failed the same way on the DeepSeek route. Repairing the stored notices by dropping the blocks the serializer cannot carry restores all of them, which confirms the diagnosis: the failure is caused by the stored notice content alone.

---

Update

@argszero reproduced this and confirmed the diagnosis. The sharper framing, and where each half stands:

• The class is wider than the settlement notice that led here. The vocabulary belongs to the serializer: reasoning and tool-call are the block types a durable user/message can carry that no DeepSeek protocol can represent there, so any producer that puts assistant vocabulary in a user message breaks a session the same way.
• UNSUPPORTED_CONTENT is not in the retryable set, so the failure is immediate and permanent. No later turn recovers, which is what makes "permanently unusable" literal rather than rhetorical.
• The regression is the asymmetry between the two serializers: chat-completions flattened the text and dropped the rest, and making Messages the default turned a silent loss into a hard one.
• Both halves belong in core. A plugin cannot wrap a built-in adapter (DUPLICATE_ADAPTER), and serialization happens inside the adapter, below the public llm/stream waterfall.
• Until that lands, the reachable half is published as a plugin: @argszero/cordis-plugin-history-sanitizer filters the unrepresentable blocks out of a request before dispatch, with an identity path when there is nothing to filter. It cannot restore what it drops, and assistant content stays out of its scope on purpose, since assistant reasoning is representable on both protocols and is required for chain-of-thought passback.

[argszero]

Thanks — this reproduces, and the diagnosis is right. Two things worth adding: the failure is broader than the notice that triggered it, and the fix point the report proposes is not reachable from a plugin, so I shipped the read-boundary half as one.

The mechanism, at line level

packages/llm/llm-deepseek/src/messages/serialize.ts maps user and tool-result content through a single input():

if (block.type === 'text')  return block.text ? [{ type: 'text', text: block.text }] : []
if (block.type !== 'image') return unsupported(`user/tool-result content ${block.type}`)

and unsupported() throws UNSUPPORTED_CONTENT. Nested tool-result content goes through the same function, so a block inside a tool result fails identically. Three consequences the report can be sharpened with:

• UNSUPPORTED_CONTENT is not in the retryable set (packages/llm/llm/src/retry-policy.ts), so this fails fast and forever — there is no path where a later turn recovers, which is what makes "permanently unusable" exact rather than rhetorical.
• The vocabulary is the serializer's, not the notice's: reasoning and tool-call are simply the two block types that can sit in a durable user message and that no DeepSeek protocol can carry there. Any producer that ever puts assistant vocabulary in a user/message poisons a session the same way; the settlement notice is the instance that was measured, not the class.
• The asymmetry the report identifies is the whole story of the regression: the sibling chat-completions serializer flattens text and drops the rest, so switching the default to Messages converted a silent loss into a hard, permanent one.

Your verification (15 sessions, 147 notice events, 140 reasoning + 82 tool-call blocks, all repaired by dropping the unrepresentable blocks) is the strongest evidence in the thread — it isolates the cause to stored content alone, and it also measures the size of the blast radius: this is not a pathological session, it is a normal upgrade path.

Why this cannot be a plugin patch to the serializer

I checked whether the fix could live where the report proposes. It cannot, from a plugin:

• registerAdapter on a built-in provider fails with DUPLICATE_ADAPTER; you cannot wrap the DeepSeek adapter from outside.
• Serialization happens inside the adapter, downstream of the public llm/stream waterfall, so a listener never sees the wire body.

So the serializer-level degrade you ask for (the way historical tool arguments already become {} instead of failing) is genuinely owed in core, and the read-boundary alternative — dropping unrepresentable blocks when the durable log is projected into a request — is core too.

The half that is reachable: a request rewrite before dispatch

While it is owed, the read boundary can be emulated on top of llm/stream: filter the offending content out of the request between the harness and its adapter, and re-dispatch. Published as a plugin:

• npm: @argszero/cordis-plugin-history-sanitizer — https://www.npmjs.com/package/@argszero/cordis-plugin-history-sanitizer
• repo (MIT): https://github.com/argszero/cordis-plugin-history-sanitizer

It ships a cordis.patch.yml, so mounting it is one config entry; with no config it removes reasoning and tool-call from user content (nested tool results included) and touches nothing else. A request that needs no filtering takes the identity path — same object, no copy, no extra dispatch. keepTypes: [text, image] switches to allowlist mode for a block type that is not known ahead of time, and observeOnly: true reports what would be removed without changing the request.

Stated plainly, it is a workaround and not the fix:

• it cannot restore the discarded blocks (the core fix should not discard them either — that is the report's "migrate on load" option, and it is strictly better than what I do);
• assistant content is deliberately out of scope: assistant reasoning is representable on both protocols and is required for chain-of-thought passback (see [Bug] 思考模式下工具调用返回 400 INVALID_REQUEST — reasoning_content 未回传 #739), so stripping it would trade one broken session for a subtler one.

I verified the end-to-end claim by driving a real @deepseek-ai/dsh-llm-deepseek@0.1.6-alpha.2 against a stubbed global fetch: with the stored notice, the request dies before the wire with 0 captured HTTP calls; with the plugin mounted, the same session reaches the wire with the blocks removed; a healthy session is untouched. The suite runs against the packed tarball on each declared prerelease line.

One seam fact, for anyone else attempting a rewrite

llm/stream is a waterfall, but the next a listener receives closes over the listener's own argument list and takes no parameters, so a listener cannot substitute the options object for the rest of the chain. A loop-assembled request is also deep-frozen, so mutating it throws. Re-dispatching a new object through ctx.llm.stream() is the only substitution path — with the caveat that the rewritten copy does not carry the loop's process-local marker, so dsh-agent-loop's request-reconstruction invariant (which only inspects marked requests) does not see it. The plugin registers with prepend: true so every other listener still observes exactly one dispatch per proposed request.

Unrelated, found while testing against each line: a pinned non-latest prerelease line is not installable in a fresh tree, with no plugin involved. dsh-llm-deepseek@X peer-requires dsh-fs@^X, and because a ^ range whose comparator carries a prerelease admits the next prerelease of the same tuple, npm resolves dsh-fs one line ahead — whose own peer requirement is the next line's dsh-llm:

peer @deepseek-ai/dsh-llm@"^0.1.6-alpha.1" from @deepseek-ai/dsh-llm-deepseek@0.1.6-alpha.1
peer @deepseek-ai/dsh-llm@"^0.1.6-alpha.2" from @deepseek-ai/dsh-fs@0.1.6-alpha.2

npm install @deepseek-ai/dsh-llm@0.1.6-alpha.1 @deepseek-ai/dsh-llm-deepseek@0.1.6-alpha.1 fails this way on a clean tree for 0.1.5-alpha.1, 0.1.5-alpha.2, 0.1.5-rc.1 and 0.1.6-alpha.1 (0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-rc.2 and 0.1.6-alpha.2 install fine). Flagging it here rather than as its own thread only because it is what a plugin author hits first when trying to test against the lines a report names.