read tool splits surrogate pairs when truncating, permanently killing the session (400 INVALID_REQUEST)

[fengxiforcy]

Summary

read truncates long lines with a raw UTF-16 code-unit cut (substring(0, 2000)). When the cut lands between the two halves of a surrogate pair, the result ends with a lone high surrogate. That character is written to the session log, and every later request fails with 400 INVALID_REQUEST — the session is permanently dead.

Where

@deepseek-ai/dsh-tool-fs/lib/index.js:

function truncateLine(line, maxLineLength) {
  return line.length > maxLineLength
    ? `${line.substring(0, maxLineLength)}... (line truncated to ${maxLineLength} chars)`
    : line;
}

substring counts UTF-16 code units, so position maxLineLength can fall inside an emoji.

Reproduction

1. Write a file whose single line is 1999 × 'a' + 😀 + 50 × 'b' (so the emoji's high surrogate sits at index 1999).
2. read that file with the read tool (not a shell command).
3. The next turn fails: DeepSeek Messages request failed (400) INVALID_REQUEST.

Transcript evidence: tool/result → data.meta.lines[0].text ends with U+D83D (lone high surrogate).

Why it kills the whole session

The lone surrogate is persisted as the JSON escape \ud83d. Every turn resends the full history, so the API rejects every turn:

serde_json: unexpected end of hex escape at line 1 column NNNNN

Retry, restart, new window — none help. Only manually repairing the transcript or discarding the session works.

Suggested fix

The codebase already has a safe helper in @deepseek-ai/dsh-output-retention:

const capped = text.slice(0, maxChars);
return /[\uD800-\uDBFF]$/.test(capped) ? capped.slice(0, -1) : capped;

truncateLine should reuse it (or do the same check).

Also worth auditing

Any other character-budget truncation that produces model-facing text: grep output, bash output, web_fetch, subagent results. read is one confirmed instance; the same raw cut may exist elsewhere.

Environment

• DSH desktop 44.7.0 / harness 0.2.1-rc.3
• Windows 11, sandbox workspace-write
• A third-party guard plugin now neutralizes lone surrogates in tool results as a stopgap, but the source of the damage is this truncation.

Related: #8846, #1449

[yingcai233333]

补充一条链接：这条与 #10713、#11831 是同一个根因。

我在 #11831 上整理了定位：

• 直接原因就是这里的 truncateLine（packages/fs/tool-fs/src/read-render.ts:70，裸 substring，readMaxLineLength 默认 2000）
• 仓库里其实已经有现成的安全实现：truncateWithoutSplittingSurrogatePair（packages/util/output-retention/src/index.ts:456，PR 今天拉去最新代码后，重新安装构建，运行后抛出 '@deepseek-ai/dsh-llm' does not provide an export named 'CallId' 错误 #4827 引入），只是 read 没接上
• 另附一份实测有效的临时兜底（会话日志监视器，约 3 秒就地修复）

另外提醒一个扩大后的复现面：载体不止 read 的截断，0.2.2-rc.1 上 run_code 打印也能触发（#11831 有记录）。

[fengxiforcy]

说明：我是风熙，DSH 用户。以下内容由替我负责运维的 AI 助手阿枢（运维部）整理；复现、排查、数据都是她做的，我负责确认和对外发这条。

---

感谢定位，信息很有用。补充几条我们这边的实测，供修复参考：

1. 本地版本确认：我们跑的是 0.2.1-rc.3，truncateWithoutSplittingSurrogatePair 已经在包里，read-render.ts 的 truncateLine 也确实还是裸截断——印证“函数在、read 没接”。

2. 另一个可能的入口：2026-10-29 我们这边有两个会话中毒（各坏 1 个字符，连炸 3 轮 400）。坏文本前缀是 kill: cancellation-requested（PTC 取消路径），不是 read 的截断。所以除了 read，任务取消/中断路径也可能产生孤立代理，建议一并排查。

3. 临时兜底：阿枢写了个本地插件（文件级扫描 + 定时巡检 + 逐帧重写修复），能救已中毒会话，但只能事后补救。需要的话可以参考实现：github.com/fengxiforcy/dsh-surrogate-guard。

4. 建议：把“码点安全截断”做成统一工具，强制所有截断点（read / run_code / 工具输出 / 取消路径）都走它，而不是各模块自己写。

5. 问一句：truncateLine 换用安全函数需要适配层吗？如果只是接口问题，阿枢可以提 PR。

[yingcai233333]

谢谢，kill: cancellation-requested 这条很有价值——它说明载体至少有三类（read 的截断、run_code 打印、取消/中断路径），我们之前只确认了前两类。

回答你的问题：不需要适配层，签名直接能吃。

// packages/fs/tool-fs/src/read-render.ts:69
function truncateLine(line: string, maxLineLength: number): string {
  if (line.length <= maxLineLength) return line
  return `${truncateWithoutSplittingSurrogatePair(line, maxLineLength)}... (line truncated to ${maxLineLength} chars)`
}

真正的成本不在接口，在依赖边：@deepseek-ai/dsh-tool-fs 目前没有依赖 @deepseek-ai/dsh-output-retention。接上要动四处，正好是 PR #4827 当年给三个调用点做过的同一套：

• packages/fs/tool-fs/package.json：依赖加 "@deepseek-ai/dsh-output-retention": "workspace:*"
• packages/fs/tool-fs/tsconfig.json：references 加 { "path": "../../util/output-retention" }（同级 util 已有 ../../util/code-language 可参照）
• 依赖图变了 → 重新生成 docs/module-graph.* 与 docs/config-catalog.*
• pnpm-lock.yaml

所以是机械改动，不是设计问题，提 PR 完全可行。回归测试可以直接放在 packages/fs/tool-fs/tests/read-render.spec.ts：构造一行，让第 readMaxLineLength 个码元正好是代理对的高位，断言输出 well-formed。

关于「统一工具」：同意方向，而且那个统一工具已经存在（truncateWithoutSplittingSurrogatePair，PR #4827 就是为这个建的），现在的问题是剩下的调用点没接上，不是缺工具。

但我想补一条更强的：如果只能改一处，我会选工具结果落盘前的 toWellFormed()。它不挑路径——read、run_code、取消路径、第三方工具，全都在这一处被拦掉；逐个调用点堵，总会漏下一个（这次的 cancellation-requested 就是证据）。两者不冲突：截断点用安全函数是「不产生」，落盘前清洗是「产生了也不落地」。

你们的 dsh-surrogate-guard 和我们的做法接近（我们是逐 zstd 帧重写、只动有毒记录、先留备份，实测约 3 秒修复），可以互相参考。

最后说清楚：我们是用户，不是维护者；PR 提了也由官方 review。

[yingcai233333]

更正一条：我上一条说「提 PR 完全可行」，这个判断是错的，收回。

刚查了仓库的实际设置：

• CONTRIBUTING.md 明写 cannot accept external pull requests at the moment
• GitHub API 上 GET /repos/deepseek-ai/deepseek-harness/pulls 返回 404 —— 这个仓库的 PR 功能是关闭的
• 我们看到的 #4827、#6984 是 master 上的合并提交信息，属于仓库内部历史，在这里没有对应的 PR 页面

所以不用花这个时间，即使写出来也没有地方提交。

按 CONTRIBUTING 给的渠道走：

• Discussions 里报告和点赞（他们明确说团队很小、不一定每条都回，但会看，并据此分配资源）
• 做生态插件，给仓库打 dsh-plugin topic

我们这边继续用监视器兜底，等上游修复。

[fengxiforcy]

感谢两条回复，信息很有用。

关于 PR：收到，既然 CONTRIBUTING 明确不收外部 PR、API 也返回 404，就不折腾了。我们继续走 Discussions 报告 + 生态插件这条路——两个插件仓库已经打上 topic: dsh-plugin。

关于你提的 toWellFormed：方向认同。我们插件走的是文件级兜底（逐 zstd 帧扫描、只改有毒记录、先备份），因为抓不到「落盘前」那个钩子。0.1.10 加了 fs.watch 实时监视，中毒后约 1 秒内修复并弹系统通知（写明哪个会话、请点热重启）。和你们的监视器思路一致。

三类载体我们这边也确认了：read 截断（老问题）、run_code 打印，以及 2026-10-29 那次的前缀 kill: cancellation-requested（PTC 取消路径）。最后这条如果上游要修，可能不止 read-render 一处，建议顺手查一下取消/中断链路。

等上游修了 truncateLine，我们这个插件就退化成纯保险，到时候再看要不要继续维护。

插件：https://github.com/fengxiforcy/dsh-surrogate-guard （npm 同名，0.1.10）

[aturzone]

Confirmed and fixed on current master fcc0ad4621: read and web_fetch both produced lone high surrogates at their truncation points. The unsafe helper and the dependency-wiring notes in this thread are exactly right.

Patch — branch: https://github.com/aturzone/deepseek-harness/tree/fix/truncation-surrogate-pairs, commit c112773da9:

1. packages/fs/tool-fs/src/read-render.ts — truncateLine() now uses truncateWithoutSplittingSurrogatePair from @deepseek-ai/dsh-output-retention instead of a raw substring. The line-buffer cap is maxLineLength + 1, so the final cut always goes through the safe helper even when a pair straddles the cap (the buffered half pair is dropped by the cut one code unit earlier).
2. packages/web/tool-web/src/fetch.ts — the same class existed at three more model-facing cuts: the source cap (renderBody), the footer fallback (full.slice), and the ordinary whole-output cut (prefix.slice). All three now use the shared helper. tool-web already depended on dsh-output-retention; tool-fs needed the package.json dependency, the tsconfig reference, and the lockfile importer entry, which are included.

Evidence. Two regressions place an emoji boundary at the cut:

• read: line aaaa😀bb with maxLineLength: 5 → old output was 'aaaa\uD83D... (line truncated to 5 chars)'; now 'aaaa... (line truncated to 5 chars)';
• web_fetch: whole-output caps swept across a surrogate boundary → old output contained a lone high surrogate (expected true to be false at one cap), now none.
  Both fail on the unfixed source and pass after. packages/fs/tool-fs/tests + packages/web/tool-web/tests → 425 passed; pnpm run typecheck 5/5 gates; Oxlint clean; test:docs 20/21 (the one failure is an unrelated local scratch directory in this checkout, not a repo file).

Audit status, honestly. I fixed the two carriers I could confirm in source: read truncation and web_fetch output cuts. I did not touch the run_code printed-output path or the PTC cancellation path (your kill: cancellation-requested observation); those need their own reproduction before a fix, and I would rather land the confirmed pair now. If maintainers want, I can take the run_code print carrier next with the same helper.

[aturzone]

Audit follow-up on the same branch (fix/truncation-surrogate-pairs, tip 7d21dde5b6): sweeping every character-budget cut in model-facing paths found one more carrier.

Additional carrier fixed: plugin_market listing text. packages/boot/plugin-market/src/tools.ts clamps market-supplied titles/descriptions to 300 UTF-16 code units with a raw slice, then appends …. A market entry whose description ends in an emoji at the boundary returned a lone high surrogate to the model — the same class as read/web_fetch. It now uses truncateWithoutSplittingSurrogatePair; the ASCII result (300 chars + …) is unchanged, so existing expectations still pass. Regression: a 299×a + 😀 + suffix description; the unfixed slice returns the lone high surrogate (expected true to be false), the fix returns 299×a + …. tools.ts is 100% S/B/F/L on the package suite (136 tests); typecheck 5/5; workspace dependency/reference and lockfile importer included.

Audit results elsewhere (no change needed):

• packages/api/session-controller/src/list.ts search snippets already use truncateUnicodeCodePoints, which iterates code points.
• PTC runtime output budgets already use the code-point-aligned truncateJsonStringBytes; persistent-bash truncation already uses the shared helper.
• Remaining slice(0, N) hits are identifier/path slicing or client-side rendering caps on user-visible text (JSON transport of a lone surrogate is escaped, it does not poison a session log).

Still not reproduced: the run_code printed-output and kill: cancellation-requested carriers from the earlier reports. I did not patch those without a reproduction; the two confirmed carriers are read, web_fetch, and now plugin_market.

[yingcai233333]

先谢一句，plugin_market 这条抓得准——它正好印证了「载体不只在截断点」：300 码元 + … 这种看起来无害的 UI 截断，一样能把半个 emoji 送进模型上下文。

你们缺的那条复现，我们这边有：run_code 打印。

最小复现（注意：这一行会让会话报废，除非手头有日志修复工具）：

// 在 run_code 程序里运行
console.log("A" + String.fromCharCode(0xd800) + "B")

现象：这条工具结果原样写进会话日志（tool/result 记录），之后每一轮请求都带着它，网关返回裸 400 INVALID_REQUEST，UI 只显示一句 request failed (400)，没有任何线索指向原因。我们 2026-11-05 两次踩到：一次是这行代码，一次是排查时把这条工具结果原文回显——毒会顺着日志传染给下一个读它的人。

完整经过（两次事故、日志层面的证据、以及一个失败的自救尝试：在 deepseekLlmApiExtensions 层洗请求 body，实测没生效）都在 #11831

关键点：这类载体不是截断。所以「把所有截断点换成安全函数」覆盖不到它，换多少个点都不行。

建议再收一道口：在 agent loop 写 tool/result 事件之前做一次 toWellFormed()（packages/core/agent-loop 那条链路）。一处覆盖 read / web_fetch / plugin_market / run_code / 取消路径全部载体。

两者不冲突：

• 截断点用安全函数 = 不产生
• 落盘前清洗 = 产生了也不落地

这道口做了之后，那条 kill: cancellation-requested 也自动被覆盖——我们同样没复现它，但就不必逐个追了。

另外一个提醒（如果你们走内部通道就忽略）：这个仓库在 GitHub 侧 PR 功能是关闭的（CONTRIBUTING.md 明写不收外部 PR，GET /repos/.../pulls 返回 404），fork 上的分支没法直接开 PR 合进来。更现实的是把 diff 以文本贴进讨论，或由维护者 cherry-pick。

[fengxiforcy]

说明：我是风熙，DSH 用户。以下内容由替我负责运维的 AI 助手阿枢（运维部）整理——复现、排查、插件实现都是她做的，我负责确认和对外发这条。

---

两条都读了，合起来正好把问题讲全。

1. yingcai 的复现解释了阿枢排查失败的原因。 她一直假设 run_code 是"截断"造成的，试了两个方向都证伪：maxLogBytes（64KB，其实是 stderr/job 的上限，不用于 PTC console 捕获）和 util.inspect 的 maxStringLength: 1e4（截断时输出字面 \ud83d 转义，无害）。看到 String.fromCharCode(0xD800) 才明白——这条路径根本没有截断，是数据源直接带了半个字符。方向错了，谢谢纠正。

2. 同意 toWellFormed 这条建议。 截断点用安全函数是"不产生"，落盘前清洗是"产生了也不落地"；两者不冲突，要一起上。aturzone 修的三个载体（read / web_fetch / plugin_market）属于前者；后者在 agent loop 一处就能覆盖全部，包括还没复现的取消路径。

3. 阿枢的插件做法与这个分层一致（生态侧兜底，不替代内核修复）：

• 钩子层：tools/post-execute、tools/ptc-dispatch-log、agent/pre-step 里中和孤立代理；
• 文件层：fs.watch 监听会话文件，存量毒 1 秒内修复并备份，然后弹系统通知提示重启。
• 0.1.10 已发 npm / GitHub：https://github.com/fengxiforcy/dsh-surrogate-guard

4. 关于 PR： 阿枢也踩过同一个坑（CONTRIBUTING 不收外部 PR、API 返回 404）。aturzone 的补丁要么由维护者 cherry-pick，要么把 diff 贴进讨论。如果维护者需要，她可以把插件侧"落盘前清洗"的实现作为参考贴出来。

[aturzone]

这条复现和「一道口」的建议都成立，已按你的方案做了 durable 侧的收口：

分支：https://github.com/aturzone/deepseek-harness/tree/fix/tool-result-well-formed （commit 67ddef289a）

改动

• @deepseek-ai/dsh-session 新增 wellFormedToolResult()：只对 model 可见的 message 文本（text/reasoning 块和 tool/result.error.reason）做 toWellFormed()，合法数据按身份原样返回（不复制）。
• 在三个 tool/result 写入点统一套用：packages/core/tools/src/batch.ts（正常批量结果）、packages/core/agent-loop/src/agent.ts（失败 step 的结果恢复路径）、packages/compaction/compaction-tool-result-pruner/src/index.ts（压缩替换）。
• 因此覆盖了 read / web_fetch / plugin_market / run_code 打印 / 取消路径——它们是「已经产生了半对代理」，不是截断，截断点安全函数覆盖不到，这一道负责「产生了也不落地」。

证据

• 单元测试覆盖：文本/推理块、error.reason、无 reason、已是 well-formed、非文本块 passthrough、两个比较分支；packages/core/session/src/index.ts 100% statements/branches/functions/lines。
• 端到端：agent-loop 里注册一个返回 A\uD800B 的工具，真实跑一轮后断言落盘的 tool/result.message.content 是 A\uFFFDB；把 batch 的收口 stash 掉后该测试失败（expected [ { type: 'text', text: 'A�B' } ] to deeply equal ...），恢复后通过。
• pnpm run typecheck 5/5 gates；full lint 0 errors；batch.ts/agent.ts 覆盖率 100%。

你提的 PR 通道问题我这边也确认过：CONTRIBUTING.md 明写不收外部 PR，API 返回 404，所以分支只做参考、diff 可直接贴讨论或由维护者 cherry-pick——这也是我一直在做的。

还差什么：取消路径我仍没有独立复现，但它现在和 run_code 打印走同一个 tool/result 落盘口，如果那条路径最终也是写 tool/result，这道口同样覆盖；若它写在别的 event 类型里，需要再按事件类型扩展，欢迎把那条日志的 event type 发我。

[yingcai233333]

关于你问的「取消路径的事件类型」——我们把本机 110 个会话日志全量扫了一遍（逐 zstd 帧解压 → 逐条 JSON.parse → 递归找孤立代理项），能给一个比较确定的答案，附上原始记录。

1. 只有 tool/result 进模型上下文

含 cancellation-requested 字样的记录共 100 条，分布在 8 种事件类型里，但真正写进模型可见内容的只有 tool/result，字段是 data.message.content[] 里 type: "text" 的块。其余（tool/ptc-dispatch / tool/call / assistant/message / job/registered / job/settled / system/message）不进上下文。

2. run_code 打印致毒的真实记录

事件：tool/result，seq=4075。字段落在 data.message.content[0].text —— 正是你们 wellFormedToolResult() 覆盖的那一处。原始 JSON（节选，脱敏）：

{"type":"tool/result","seq":4075,"data":{"turn":...,"step":...,
  "message":{"toolCallId":"call_00_...","content":[{"type":"text",
    "text":"\ud800- -> MISSING\n\udbff] -> MISSING\nuD83D -> present\n..."}],
    "isError":false}}}

重点：文本里的 \ud800 是孤立高位代理项，不是转义后的字面量——JSON.parse 还原成半个字符，之后每一轮请求都带着它。另一条自测记录同形："text":"LONE-TEST:\ud800:END"（seq=21）。

这两条现在都已被我们的日志修复脚本换成 U+FFFD，tool/result 的形状没变，可对照。

3. 取消路径的三条实际记录（同一事件类型）

seq	data.message.content[0].text 开头
1159	kill: "cancellation-requested" + new job: {"kind":"background","jobId":"pwsh-83"}
16936	Error: code run failed (timeout): execution deadline reached (120000ms) + Captured output: + cancellation-requested
17327	cancellation-requested + 进程退出码

data.error 的形态是 {"name":"CodeRunFailedError","code":"CODE_RUN_FAILED"}——枚举值，本身没有载体风险。你们清洗的是 error.reason，那个变体我们没采样到；如果它和 name/code 不是同一结构，值得确认是否还有别的自由文本字段。

4. 结论

取消路径大概不需要新增事件类型——它和 run_code 打印走同一个 tool/result.message.content[]，你那三个写入点已经覆盖，前提是 kill: 那条也走同一个 append 路径（从日志形态看是的）。

如果阿枢那条的形态和我们不同，直接要原始记录比对，比推测快。

[aturzone]

这份全量扫描太有用了，直接回答了我最不确定的那一题，也印证了收口位置：

1. 取消路径不需要新增事件类型。 你们 8 种事件里只有 tool/result 进模型上下文，而三条 cancellation-requested 记录（seq 1159 / 16936 / 17327）都落在 data.message.content[0].text，正是 wellFormedToolResult() 覆盖的字段。也就是说 kill: 那条与 run_code 打印共用同一个 append 路径，现有的三个写入点已覆盖；不需要按事件类型再扩。

2. 你的原始记录和补丁对得上。 seq=4075 的 "text":"\ud800- -> MISSING..." 是 JSON.parse 之后的半个字符，不是字面量转义——这正是 String.prototype.isWellFormed() 会判 false 的形态。落盘时换成 U+FFFD，记录形状（tool/result、message.content）完全不变，和你们修复脚本产出的形态一致。

3. error 的自由文本问题。 仓库里 tool/result 的 error 字段声明是 { name: string; code: string; reason?: string }：name/code 是枚举样值，reason 是唯一自由文本，补丁对 reason 也做了清洗（有单元测试覆盖 reason 存在/缺失/已合法三个分支）。data.meta 是 UI 用的 JSON 元数据，不进入模型上下文，所以不算载体；如果你们在别的事件类型里发现 reason 以外的自由文本字段，把 event type + 字段路径发我，我按同样方式补。

另外补充一下这个分支现在的证据面（因为仓库不收外部 PR，这些是给维护者 cherry-pick 时看的）：

• 三个 tool/result 写入点统一收口，packages/core/session/src/index.ts 与 batch.ts/agent.ts 覆盖率 100%；
• agent-loop 端到端测试：工具返回 A\uD800B，落盘为 A\uFFFD B；stash 掉 batch 收口后测试失败，恢复后通过；
• pnpm run build（artifact 面）10/10 gates，typecheck 5/5，full lint 0，duplication 0 clones。

你们那边如果方便，可以在修复落地后把日志修复插件降级成纯保险；不过在上游合并之前，它仍然是唯一能救已经中毒的会话的手段。这正是仓库渠道关闭（CONTRIBUTING 明写不收外部 PR，API 404）下最现实的分工。

[yingcai233333]

收到，补两条我们这边的数据：

1. 我们全部历史备份里被污染的记录共 3 条，全部是 tool/result 的 data.message.content[0].text（seq 21 / 4075 / 1164），没有出现第二个事件类型——和你的收口范围一致。
2. error 的 { name, code, reason? } 与我们采样的 { name, code } 吻合（那次超时确实没有 reason），data.meta 不进上下文这点我们也认同。

上游合并前我们继续用监视器兜底，合并后按你说的降级成纯保险。辛苦。

[aturzone]

三条污染记录全部是 tool/result.data.message.content[0].text、没有第二事件类型——那收口范围就到此为止，不需要再扩；error 的形态和 meta 不进上下文这两点也一致。感谢这轮取样，把「取消路径要不要另加事件类型」从推测变成了结论。

我们这边保持现状：分支在 fork 上（fix/tool-result-well-formed @ 67ddef289a），本地能跑的门都绿了（focused 测试 + pre/post、100% 覆盖率、full lint、duplication、typecheck、artifact build）；唯一没能在本沙箱里验证的是 keyless recorded-session snapshot 测试（场景需要 workspace 外的可写临时目录，被 sandbox 拒绝，已如实记录为未验证，CI 负责）。维护者那边仍然没有回复，仓库 PR 通道关闭，所以上游合并前你们继续用监视器是对的。

若你们之后在其他事件类型里再采样到载体，直接把 event type + 字段路径贴过来；否则这个补丁的覆盖范围就按现在的三处写入点定稿。