DeepSeek Harness 400: lone surrogates, empty blocks

In DeepSeek Harness (DSH), the most misjudged class of failure is "400 on every turn": the error looks like a model or network problem, opening a new session fails just the same, and restarting does not help — because the poison is not in this one request, it is in the history, and the history is resent in full every turn. This batch of discussions splits the family into four independent kinds of "invalid request body": illegal Unicode (an outbound message containing a lone surrogate, or the read tool truncating by UTF-16 code unit and splitting an emoji into a lone high surrogate); empty content blocks (a reasoning block persisted with text: "" when the model returned no reasoning content, or the adapter putting a pure-whitespace text block like {"text":"\n"} into the replay); a content-moderation hit (Content Exists Risk, a content property + resent every turn = permanently locked); and a reference-parser false hit (a dsh-session: plus a run of digits in a message is treated as a session reference and decoded, and a failure throws for the whole turn). The shared test for all four is: the error contains a searchable literal, yet syntax checks such as JSON.parse all pass (#9089, #8846, #9435, #8830, #9613).

DeepSeek Harness illegal Unicode: lone surrogates and code-unit truncation

In one sentence: JavaScript string operations count by UTF-16 code unit, an emoji takes two code units, and once the truncation point lands in the middle it produces a lone surrogate; it is written to disk as valid JSON (\ud83d), but the server's content validation judges it semantically invalid, so the whole turn is rejected. Both sources have really occurred: external content carrying a bad code unit, and DSH's own read tool truncating (#9089, #8846).

DeepSeek Harness mechanism: why "syntax-valid" still fails

1. JSON.stringify writes a lone surrogate as an escape sequence like \ud83d — this is completely legal at the JSON syntax level, so any JSON.parse check reports no error;
2. The server's Messages endpoint does a content check (Unicode validity), not a syntax check, so the whole request is rejected with a 400 and no locator information;
3. Once the bad value enters session history it is resent with the history every turn, hence "the session fails forever, and a new session fails too";
4. What the code side lacks is entry validation: llm-deepseek's buildMessages does only structural validation, with no Unicode validity check; the read tool's truncation constant is 2000 code units (not code points), split with String.prototype.substring, and cutting in the middle of an astral character produces a lone high surrogate (#8846).

DSH plugin three-step locate: the bad value is "visible ASCII" in the file

1. Rough-scan the session file for lone surrogates (they land on disk as plaintext escapes you can regex directly):

Select-String -Path "<session file>" -Pattern '\\u[dD][89abAB][0-9a-fA-F]{2}' -AllMatches |
  ForEach-Object { $_.Matches } | Group-Object Value | Sort-Object Count -Descending |
  Select-Object -First 10 Count, Name
#   expect: it lists suspicious high-surrogate escapes such as \ud83d

2. Confirm it is really unpaired: a high surrogate (\uD800–\uDBFF) must be immediately followed by a low surrogate (\uDC00–\uDFFF). If what follows is not a low surrogate, it is a lone surrogate (#9089).
3. Confirm the source: if the bad value appears in the read tool's return and its position is right around the 2000th code unit, you can be fairly sure it was a truncation splitting a surrogate pair (#8846).

DeepSeek Harness fix: replace the bad code unit and re-encode only its frame

1. Back up the session file, then process it "line by line": copy the whole file → JSON.parse each line → scan for unpaired surrogate code units → replace with U+FFFD → re-encode only the frame it lives in, without renumbering (#8846).
2. After re-encoding, scan once more to confirm no lone surrogates remain, then write back.
3. State the cost honestly: replacing with U+FFFD means half an emoji becomes �, which is a lossy fix; the thread also mentions a community offline tool that can do this kind of lone-surrogate handling (#9089).
4. Stop the bleeding before fixing: if some plugin injects bad content into the history every turn, you must first stop that injection source, or it recurs right after the fix (#9089).
5. The code-side proper fix: normalize once at the entry with text.toWellFormed(), or make the truncation code-point-aware (#9089).

DeepSeek Harness empty content blocks: empty reasoning and pure-whitespace text

In one sentence: when the model returns no reasoning content, the Harness still persists a reasoning block with an empty text; the adapter then unconditionally serializes every reasoning block into a native thinking field, and the empty block sent as thinking:"" is rejected — turning thinking off cannot save it either, because the bad block is in history. The other shape is a pure-whitespace text block ({"type":"text","text":"\n"}) wedged between two tool calls, which makes the cloud API split the message (#9435, #9239, #8836).

DeepSeek Harness three error shapes and their mechanisms

According to community source-level confirmation, the key gap on the code side is "the asymmetry of the drop-empty-block decision": interruptedBlocks() drops empty blocks, while the keep/drop decision in assembled() does not; meanwhile assistant() cannot get the thinking policy, so setting reasoningEffort to off also cannot change the serialization of empty blocks in history (#9435). On the whitespace-text side, the text branch of serialize.ts has no empty-block guard, and the suggested fix is to change the check to text.trim().length === 0 (#8836).

DeepSeek Harness four-step fix: block-level delete plus one invariant you must obey

1. Locate the empty blocks: search the session file for empty thinking / reasoning content:

Select-String -Path "<session file>" -Pattern '"thinking":""|"text":""|"text":"\\n"'
#   expect: a few hits, which are the empty blocks

2. Back up, then do a block-level delete (no renumbering needed — this is where it is easier than the Unicode class) (#9239).
3. At the same time delete the entry at the same position in replayState.blocks — this is the most important invariant here: if you only delete the message block without touching the index, assembler drops the whole envelope for a count mismatch, throwing the signature away with it, and the failure escalates from "one block is broken" to "the whole segment is broken" (#9239).
4. Prevention side: the community plugin @argszero/dsh-empty-block-guard wraps the return value of llm/stream to stop new empty blocks from landing on disk:

npm i @argszero/dsh-empty-block-guard

Boundary: the prevention plugin can only prevent "new blocks"; already-poisoned logs must be fixed offline. Also be careful not to write "drop empty blocks" too broadly — a naive || check will wrongly hit blocks that carry tool calls (#9435).

DeepSeek Harness moderation lock: content property + resending every turn = permanent failure

In one sentence: Content Exists Risk is a content property, not an entry-point property, and because the history is resent in full every turn, one record that crosses the line makes the session fail forever — even copying the session carries the poison. The thread summarizes the family as "two mechanisms, three poison sources, three faces", and confirms there is also a response-side kind of refusal (MALFORMED_RESPONSE) that recurs every turn (#8830).

DeepSeek Harness three-step handling

1. First judge whether the session is alive by turn/end: receiving turn/end means the turn ended normally (a response-side stream cut / refusal), while not receiving it and only getting a 400 means the request side was rejected. The two paths are handled differently (#8830).
2. The only verified recovery path is "fork before the poison": fork a new session at the position before the error, leaving the offending stretch of history behind in the original session (#8830).
3. Try to earn automatic recovery: add the corresponding error code to that profile's retryableCodes, or use a community plugin that maps refusals to retryable, giving the request-side 400 a chance to continue after a narrowed resend; the thread also mentions a community plugin that narrows and resends incrementally to keep going (#8830).

Key point: for the moderation class, never expect "just switch the entry point" to work — opening a new session and carrying the history over is moving the poison along with you.

DeepSeek Harness reference-parser false hit: dsh-session: in a message kills the whole turn

In one sentence: the session-reference parser treats any bare text of "dsh-session: plus a run of alphanumerics" as a reference and tries to decode it; plain digits are a legal form too, and a failed decode throws, while the call site has no try/catch, so the whole turn fails. Even pasting the error text that contains that literal into a help request fails the same way (#9613).

According to the reporter's source check: prepareDirectMessages() in @deepseek-ai/dsh-session-reference calls parseSessionReferenceText on each user message's text block; the bare-text branch of the regex matches "scheme + [A-Za-z0-9_-]+", plain digits are legal → base64url decode, and a failed JSON.parse throws SESSION_REFERENCE_INVALID_REFERENCE; the four versions and master are byte-for-byte unchanged (#9613).

Handling steps:

1. Locate: search the message text for dsh-session:; a hit followed by an ordinary number / short string is the false hit.
2. Short-term avoidance: escape or rewrite that prefix (for example insert a space, or use a full-width colon) so the parser does not recognize it.
3. Mitigation plugin: the community plugin @argszero/dsh-session-reference-guard registers on the same waterfall with prepend: true, rewriting only the literal that would be rejected; the author himself labels it a stopgap, not a fix (#9613).
4. Proper fix direction: this layer should fail-open — a failed parse should be treated as ordinary text rather than failing the whole turn.

DSH plugin troubleshooting notes

The mnemonic for "400 every turn" is: first use the error text as a keyword to search the logs, and if you find it you have located it directly; if you cannot, then judge by "does a new session fail too" whether the poison is in the history or in the current input. Nine points:

1. A passing JSON.parse check ≠ valid content: a lone surrogate's escape sequence is completely legal syntactically, so do not use it to rule the problem out (#8846).
2. The bad value is usually visible ASCII in the file, and a regex rough-scan is far faster than reading by hand (#9089).
3. Truncation and slicing must be by code point: anywhere that cuts a string by "length" can split a surrogate pair, and this is the family's manufacturing machine (#8846).
4. Deleting an empty block requires deleting replayState.blocks in step: this is the family's most expensive invariant, and forgetting it amplifies a small failure into a whole-segment failure (#9239).
5. Turning thinking off cannot cure the history's disease: the empty blocks in history are still serialized (#9435).
6. For the moderation class, remember the words "content property": switching entry points and copying sessions both carry the poison, and only forking can save it (#8830).
7. dsh-session: is a literal trigger, unrelated to whether the session actually holds a reference (#9613).
8. Always back up before fixing: all four fixes edit session files directly, and a backup is the only way back.
9. State the fix status honestly: all four are unfixed in the versions the discussions refer to; the available means are "offline cleanup of already-poisoned logs + plugins to prevent new blocks", which is user-side handling, not an official fix.

Troubleshooting this kind of problem often requires first confirming "is some plugin injecting bad content" — especially for the empty-block and reference-false-hit classes, where the injection source is often a third-party plugin. If you want to see plugin installs/uninstalls and logs in a UI first, rather than typing commands in various places, use a visual plugin marketplace such as DSH Plugin Hub: the installed list, install/uninstall history, and system logs are collected in one panel, and locating "who is writing bad things into the history" is much faster.

Source: Discussion #9089, Discussion #8846, Discussion #9435, Discussion #9239, Discussion #8836, Discussion #8830, Discussion #9613.