长会话被输入审核整段熔断（400 Content Exists Risk / INVALID_REQUEST）：能否提供历史定位与会话级旁路？

[dddwdee]

### 现象

一次普通的技术调研中，工具抓取了一个第三方 GitHub raw 页面（约 8 KB 中文正文，含一对 U+1F1E6–U+1F1FF 区间的区域指示符，即显示为国旗图形的符号）。该正文进入对话历史后，**该会话的所有后续请求**都返回：

    HTTP 400  {"message":"Content Exists Risk","code":"INVALID_REQUEST"}

### 关键判据：判定的是历史，不是新输入

- 同会话中把新消息缩短成两个字符（`test`）→ 仍然 400；
- 新建会话只发 `test` → 正常。

### 后果

1. 该会话不可恢复：报错不指明是哪条历史、哪个 token 区间、哪一类规则；也没有任何 API 层面的会话恢复出口，只能整段删除会话。
2. 排查过程本身会复现故障：为定位原因而读取旧会话转录 / 页面副本的会话，会立刻以同一原因失效——本次共 **6 个会话**依次熔断。
3. 一次无害的第三方文本抓取即让整段工作上下文作废，属单点不可逆故障。

### 复现（建议在隔离的调试环境）

1. 在全新会话中抓取该页面正文并写入会话（页面地址可私下提供；**请勿在生产会话里抓取**）；
2. 在同一会话继续发送任意新消息（如 `test`）→ 此后全部 400；
3. 对照：新会话只发 `test` → 正常。

### 请求

1. `INVALID_REQUEST` 的响应体附带**历史定位元数据**（触发消息序号/时间戳、触发类别），不回显敏感原文；
2. 提供**会话级旁路**（按序号截断/删除历史后重试），而不是永久 400；
3. 文档补充该错误码的触发条件与恢复路径（当前官方错误码页只列 400 格式错误/401/402/422/429/500/503，未收录它）。

### 环境

DSH Desktop 0.6.4（内核 `@deepseek-ai/dsh` 0.1.5-rc.2），Windows，2026-09-19。

> 附：脱敏后的完整报告（已移除本机路径、用户名、账号标识与第三方页面地址，不含任何触发字符）。如需页面地址用于复现，请告知，我可私下提供。

两点提醒

• 勾选「我搜索过类似的讨论」前先真的搜一次（关键词：Content Exists Risk、INVALID_REQUEST），命中同题就在那帖回复。
• 附件要用脱敏版（ContentExistsRisk-事件报告-公开版.md）重新上传；旧附件若已含本机路径，删除草稿里的引用并不能收回那个已上传的 URL。

ContentExistsRisk-事件报告-公开版.md

[starxjys]

东南小岛flag会Content Exists Risk

[argszero]

Thanks for the precise report — the flag-symbol observation and "a 2-character new message fails identically" are the two facts that pin this down. Here is the mechanism, and a plugin-shaped answer to both halves of your question (localization + a session-level bypass).

Why the session, not the turn, is broken

Nothing about your new message is being rejected. The request that fails contains the whole conversation: the loop re-derives it from the session log on every call, and GenerateOptions.messages is documented as "ordered conversation messages, exactly as the provider sees them" (packages/llm/llm/src/types.ts:455-467). The rejection is a property of content, not of a turn — so once one durable record trips moderation, every later request carries it and fails, whatever you type. That is the same shape reported in #6495 (turn 1 of a brand-new session) and #6476 (a session whose failure is inherited by whoever reads it).

Two consequences worth stating, because they rule out the obvious fixes:

• Retry is not available. llm-retry routes on the provider's retryableCodes; a deterministic 400 is not in that set, and retrying identical content would fail identically.
• Editing the log is not available either. The harness has no path that rewrites stored content, and the loop hands the request to the waterfall deep-frozen — its content is deliberately "a pure function of the session log". Listeners read it, never rewrite it (packages/llm/llm/src/index.ts:62-72).

The one lever that is left is what is sent, not what is stored. That is also the honest limit of the fix below: it does not remove the poison from your log, it stops the poison from being transmitted.

A plugin that does exactly that

@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

It uses your rule — insert a space between every pair of adjacent characters when neither is a space, newest messages first — but spends it reactively, so a healthy session pays nothing:

1. Every request is first dispatched untouched (next() with your own object: no copy, no tokens, no cache invalidation).
2. If the provider refuses it with the moderation rejection, that refusal is the signal. The plugin retries with the newest N messages spaced out, escalating a ladder (ladder, default [4, 32, 0]) — a rung's refusal is the evidence it was not enough, so nothing is paid for messages the retry proved irrelevant.
3. A rung that is accepted latches the session to it (in-process, keyed by sessionId), so later requests skip the doomed probe and start where it works.
4. A refused attempt's terminal frame is held back while another rung is available (a moderation 400 arrives before the provider streams anything, so nothing the consumer saw is at risk), and 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.

Mounting needs no configuration:

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

On your first question — locating the history that triggers it

The ladder doubles as a localization tool, and this is free: the rung the provider finally accepts bounds the trigger's depth ("the newest 32 messages suffice" ⇒ it is within those 32, and the newest 4 are not enough). And if every rung is refused, the trigger is outside what the plugin can rewrite — assistant content (roles defaults to ['user'], which is where fetched content lands), tool-call arguments (a raw JSON string; a character transform would corrupt it), or a tool schema — which is itself the localization answer. mode: observe reports each rung's scope and cost without rewriting anything, if you want the measurement without the rewrite.

Mechanics you may care about

The rewrite must be a re-dispatch, not an in-place edit: llm/stream is a waterfall but its last argument is the innermost next, and cordis closes over the listener's argument list — next takes no parameters, so a listener cannot substitute the options object. So the plugin calls ctx.llm.stream() with a new request, registers with prepend: true so every other listener sees exactly one dispatch per proposed request, and keeps a WeakSet of its own replacements so the re-dispatch terminates. Stated plainly in the module doc: the rewritten request is a new object, so it does not carry dsh-agent-loop's process-local marker (markAgentLoopRequest is a WeakSet; a shallow copy is not a loop request) and the reconstruction invariant does not inspect it — a request that could not have been sent at all is the one case where that equality is knowingly broken.

The transform itself iterates code points, so a surrogate pair is never split (your flag symbols are exactly this case), and never inserts ahead of a combining mark or a zero-width joiner, so an emoji sequence keeps rendering as one.

Evidence

47 tests against a real @deepseek-ai/cordis context and a real @deepseek-ai/dsh-llm runtime, with a stub provider that refuses a request the way moderation does (a terminal error finish with {message: 'Content Exists Risk', code: 'INVALID_REQUEST', status: 400}, and no content). The unmounted control arm fails on the same request, which 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, an undeclared import, a stale dependency) each turned the suite red.

Known boundaries, honestly: assistant/system content is opt-in (roles); tool-call arguments and tool schemas are never rewritten; purpose-carrying auxiliary calls (compaction, session title) are skipped by default because their output is folded back into the session; and a rung that fires invalidates the provider's prefix cache from the first rewritten message onward, and roughly doubles the characters it touches. Those costs are paid only by a session whose alternative is failing every turn.

[mengge237]

补一份客户端事件流侧的读数，机制那部分上面 argszero 已经讲清了，我不重复，只补「用户当时能知道什么」这一维。

口径：~/.dsh/sessions/**/session.jsonl.zstd 全量解压后只看 turn/end 的 data.reason。本机 121 份存档 / 702 个回合结束事件（运行时 0.1.5-rc.2）：

• completed 544、error 65、aborted 62、max-tokens 29、interrupted 2
• 65 个 error 的 code：QUOTA 33、UNKNOWN 14、AUTH 7、TRANSPORT 4、NO_ADAPTER 4、INVALID_REQUEST 2、UNSUPPORTED_REASONING_EFFORT 1
• 65 个里只有 8 个带 status（全部来自 QUOTA 那批，带 402）
• 楼主报的 Content Exists Risk 这个报文：本机 0 命中，没复现，这条只当侧证

有用的是那 2 个 INVALID_REQUEST，它们是两件完全不同的事：

1. <400> InternalError.Algo.InvalidParameter: The content field is required in messages. —— 请求体参数错误；
2. 400 data: {"error":{"code":"data_inspection_failed","message":"Input text data may contain inappropriate content."}} —— 输入侧内容审核命中。

也就是说，审核命中落到客户端事件流里，和「参数写错」共用一个 code，而且 HTTP status 没带下来。这时候用户分不清的第一件事不是「哪条历史触发的」，而是这次失败到底是不是审核——因为下一步动作不同：参数错误要改调用，审核命中要么改输入、要么止损换会话，而目前两种情况在日志里长得一模一样。

所以我想把「请求 1」往下压一小步，成本比历史定位低得多：

1. 先把审核命中从 INVALID_REQUEST 里单列一个稳定 code（CONTENT_RISK 之类）；
2. 顺手把 status 落上——这个字段本来就在，QUOTA 那 33 例就带着 status: 402，审核类只要走同一条落码路径。

这两步不动 API 响应结构，只是在现有分类里加一支。有了它，「命中在哪条历史」可以作为第二步再谈；用户侧至少当场能判断该重试、该改输入、还是该弃会话。

我方在这条上的代价可以作参照：为了在日志里分清这个码，我们在自己插件侧补过一处分类，代价是每升一版要重打一次。止损那一半上面已经有现成插件覆盖了，我不重复；只是这件事放在发行件里做一次，比每人各打一处补丁划算。

最后一条排查提醒：GET /notifications/threads/<id>/subscription 这类接口在 token 缺权限时回 404 而不是 403，「读不到」和「不存在」长得一样。排查这类问题先拿一条已知存在的记录做正对照，否则很容易把权限问题误判成数据问题。