违禁词命中导致 DeepSeek 直接拒掉整条请求 → 会话永久卡死，且会被读取它的会话继承（附确定性最小复现）

[kingbob-1]

EN TL;DR — A banned word in the request content makes the DeepSeek API reject the whole request
(400 Content Exists Risk). Because that word stays in the session history, every later request replays it,
so the session becomes permanently unusable; worse, any other session that reads that content gets
poisoned the same way. Deterministic minimal repro included; related discussion: #5445.

---

一句话

请求内容里出现了违禁词（就是 "xx事件" 这一类词），DeepSeek 服务端直接拒掉整条请求
（HTTP 400，Content Exists Risk）；因为这个词留在了会话历史里，之后每一轮请求都会把它一起发出去，
于是整个会话此后每轮必败，重试、换说法都无效。相关现象见 #5445（那里有附件样本）。

环境：DSH 0.1.1-rc.2、模型 deepseek-flash（provider deepseek-official）、Windows 10。

确定性复现

1. 最小触发单元 = 4 个字符（2 个数字 + "xx事件"）。把它单独作为一条 user 消息发给
   POST https://api.deepseek.com/chat/completions：
   • 连续 3 次 → 400 Content Exists Risk（code=invalid_request_error）；
   • 换成无关中文（4 字 / 20 字）→ 200；
   • 该词前后加空格、或放进一句自然语言里 → 仍然 400（说明只看是否出现，与上下文无关）；
   • 只取它的前 2 个字符 / 后 2 个字符 / 第 1+3 个字符 → 200（是"组合"才触发）。
2. 真实会话样本（附件 s10_turns_6_7.txt 见 长会话触发 Content Exists Risk / INVALID_REQUEST，整个会话被 400 拒绝，能否恢复？(dsh + DeepSeek API) #5445，共 20 行）：
   • 整份文件作为一条 user 消息 → 400；
   • 第 3 行单独发 → 400；第 1–2 行、第 4–20 行单独发 → 200；
   • 第 3 行是某会话某一轮的工具结果（一条命令的输出）——也就是这个词进入上下文的入口。

为什么比"偶尔一次报错"严重

1. 永久性：历史被反复重放，每一轮都撞这个词 → 会话卡死；而会话文件本身完全正常
   （seq 连续、无损坏），从文件层面看不出问题，用户只能看到"每轮都失败"；
2. 会传染：另开一个会话去读取（查证）这个会话的内容，读完那个会话也开始每轮 400
   —— 我实测复现过两次（一次人工、一次用裸 API 请求）；也就是说"去查证/修复"这个动作本身会扩散问题；
3. 唯一恢复方式是把含这个词的轮次删掉（把内容从历史里去掉），会话即可继续；
4. 目前的错误呈现看不出原因：400 被统一映射为 INVALID_REQUEST
   （packages/llm/llm-deepseek/src/adapter.ts 的 httpErrorCode），既没有"供应商内容拒绝"这一类独立错误码，
   也没有任何"这段历史无法重放，建议删除某轮"的向导。

建议

1. 独立错误码：把"供应商内容拒绝"从通用 400 里分出来（例如 CONTENT_REJECTED），
   这样宿主/客户端才能给出正确引导，而不是把它当成参数格式错误；
2. 恢复向导：失败时定位"最近进入上下文的那条工具结果"，提示用户可删除该轮或该条结果；
3. 根本上：一条工具结果不应该让整个会话永久失效 —— 例如重放前对历史做一次本地扫描，
   或允许"跳过某条历史"；另外 [Bug/提案] 纯推理轮到 content or tool_calls must be set，毒死整会话：(serialize) 层缺少对 reasoning-only 空 content 的兜底 #5466 指出的"reasoning-only 空 content 毒死会话"是同一类问题的另一个入口，
   建议一起考虑。

相关

• 长会话触发 Content Exists Risk / INVALID_REQUEST，整个会话被 400 拒绝，能否恢复？(dsh + DeepSeek API) #5445 —— 同一现象（长会话触发 Content Exists Risk、整会话被 400 拒），附件 s10_turns_6_7.txt 可复现；
• [Bug/提案] 纯推理轮到 content or tool_calls must be set，毒死整会话：(serialize) 层缺少对 reasoning-only 空 content 的兜底 #5466 —— 另一条"会话被永久毒死"的路径（纯推理轮的空 content 序列化缺少兜底）。

该词涉及敏感话题，具体是哪几个字我不写出来，上面统一用 "xx事件" 代指。

[Huang22333]

对的，我也遇到了，而且他不像小米mimo，小米是报“Considered high risk”然后中断输出，但是上下文还能继续用，但是DS的话上下文污染了，对话就废了，只能说从上一轮创建分支

[Kazerujoy]

运行任务的时候查到了某条新闻，类似习特会那种，直接污染整个历史会话和几个尝试修复的会话，全部返回http 400我还奇了怪了。历史请求点进去才发现这个问题。

[argszero]

Thanks for the deterministic minimal repro — the four-character trigger, "spacing it inside a sentence still 400s", and "any two-character subset 200s" together settle that this is a match against the whole replayed payload, not a per-turn check, and your "reading it back poisons the reader" finding is the part that turns it from a nuisance into a hazard.

Perry Link's mechanism analysis in #5445 is the accurate frame, and its bullet 1 ("去掉或改写后重试") is exactly the recovery shape. This reply adds the piece neither thread carries: a working, installable plugin-form mitigation for the session-poisoning case, so a session whose only other option is failing every turn can keep going.

The plugin

@argszero/cordis-plugin-content-exists-risk@0.1.0

• npm: https://www.npmjs.com/package/@argszero/cordis-plugin-content-exists-risk
• repo: https://github.com/argszero/cordis-plugin-content-exists-risk

Mounting needs no configuration:

- insert:
    - id: content-exists-risk
      name: '@argszero/cordis-plugin-content-exists-risk'

What it does

It is reactive, so a healthy session pays nothing:

1. Every request is dispatched untouched first — no copy, no tokens, no cache invalidation.
2. Only if the provider refuses it with the moderation rejection does the plugin act on that refusal as its signal: it re-dispatches a fresh ctx.llm.stream() whose content has a space inserted between every pair of adjacent characters where neither is a space, newest messages first, escalating a ladder (default [4, 32, 0]).
3. A rung that is accepted latches the session to it (in-process, keyed by session id), so later requests skip the doomed probe and start where it works.
4. While another rung is available, the refused attempt's terminal frame is held back (the rejection arrives before the provider streams anything, so nothing the consumer saw is at risk); when every rung is refused, the provider's own failure is surfaced unchanged. The plugin never turns a failure into a success it did not observe.
5. Idempotent; emoji / ZWJ sequences / combining marks are never split.

Nothing here bypasses the upstream content policy — when the platform refuses every rung, you get exactly the provider's error back.

Where it can reach — honestly

Your carrier is the tool result (turn 3's command output). ToolResultMessage.role is 'user' (packages/llm/llm/src/message.ts:164-169) and the rewrite descends into tool-result blocks, so that entry point is covered by default:

Trigger location	Role	Reachable with default roles: ['user']?
User message text	user	yes
Text nested inside a tool result	user	yes (recursed)
Assistant message text	assistant	needs roles incl. 'assistant'
Tool-call arguments	— (raw JSON, no text)	no — unreachable by design

Boundaries, stated plainly: it does not remove the poison from your log, it stops the poison from being transmitted. Assistant content is opt-in via roles; tool-call arguments are a raw JSON string, so a character transform would corrupt them and is never applied. If every rung is refused, the trigger is outside what the plugin can rewrite — that "all rungs refused" outcome is itself the localization answer, and mode: observe reports each rung's scope and cost without rewriting anything if you want the measurement alone. The rung that fires invalidates the provider's prefix cache from the first rewritten message onward and roughly doubles the characters it touches; that cost is paid only by a session whose alternative is failing every turn.

On your two proposals

An independent error code (e.g. CONTENT_REJECTED) split out of the generic 400, plus a recovery guide that names the most recently ingested tool result, are core-side changes and worth doing — they would make this legible instead of an INVALID_REQUEST. This plugin does not depend on either landing; if the split does land, it can key on the code instead of matching the message string. It is additive to whatever upstream decides.

Evidence

47 tests against a real @deepseek-ai/cordis context and a real dsh llm runtime, with a stub provider that refuses the way moderation does (terminal error finish carrying {message: 'Content Exists Risk', code: 'INVALID_REQUEST', status: 400}, no content). The unmounted control arm fails on the same request — that control is what makes the rest evidence rather than assertion. Nine mutations of the implementation (transform disabled, hold-back guard removed, attachment protection removed, rung off-by-one, latch not written/not read, rejection gate removed, undeclared import, stale dependency) each turned the suite red.