【BUG】heredoc / 单行命令含 ! 会导致整个命令行挂死

[lanchestios]

调研闭环。以下是基于 deepseek-harness 源码的系统性定位报告。

---

Bug 报告：bash 工具遇 ! 字符挂死 300 秒

一句话结论

命令投递层用 ANSI-C 引用（$'...'）包裹模型命令，但受控 shell 是交互式 bash（history expansion 默认开启），$'...' 不像单引号那样豁免 !——含 ! 的整行被 bash 以 event not found 整行丢弃；丢弃后的提示符不带完成检测标记，工具层又没有对此状态的早退，三者叠加导致空转到 300s 超时。

最小复现（已实证）

命令 printf 'p4-start %s p4-end\n' '!' 被投递层包成（tool-bash-persistent/src/index.ts:82 wrapCommand）：

printf '%s\n' $'__DSH_START__'; eval -- $'printf \'p4-start %s p4-end\\n\' \'!\''; __dsh_s=$?; printf '%s%s\n' $'__DSH_END_:' "$__dsh_s"

喂给与生产完全同构的 bash --noprofile --norc -i（PS1=dsh> 、PROMPT_COMMAND 发 OSC 133;D），输出逐字：

bash: !\: event not found
dsh>                        ← 裸提示符，注意：前面没有 OSC 133;D 标记

START printf、eval、END printf 全部未执行。

三层根因

层 1｜触发层：quoteForBash 的引用形式不防 history expansion
packages/shell/tool-bash-persistent/src/index.ts:74-78

function quoteForBash(value) { return `$'${…replaceAll("'","\\'")…}'` }

• 转义了 \ 和 '，唯独没处理 !；
• shell 以 --noprofile --norc -i 启动（terminal-bash/src/config.ts:65）——交互模式，histexpand 默认开，初始化序列（index.ts:273 只有 stty -echo）没关它；
• bash 在读行时先做 history expansion（先于任何解析/执行）：! 后跟 \' 被当作事件标识符 !\，查找失败 → 打印 event not found → 丢弃整行。bash 的历史扩展对单引号内字符豁免，对 $'...' 不豁免。

层 2｜放大层：丢弃行后的提示符缺少完成标记
packages/terminal/terminal-bash/src/index.ts:83-87、sanitize.ts:6

• 完成检测协议 = PROMPT_COMMAND 打印 \033]133;D;<exit>\007，sanitizer 只认这个 OSC 为 prompt；
• 但 bash 在 history-expansion 丢弃行后重打的提示符不执行 PROMPT_COMMAND（复现输出可见：错误后是裸 dsh> ，之后的正常命令才带标记）；
• 于是 session.ts pollReadiness 的 stdin_read 分支（:567-571，要求 promptSeen && promptTextSeen）永不满足，只剩 inferred_idle（:596）兜底结算。

层 3｜空转层：工具循环对 inferred_idle 无早退
packages/shell/tool-bash-persistent/src/index.ts:321-389

while (true) {
  …startSend({ text: first ? wrapped : '', submit: first })   // 空轮不写入、不重置 readiness
  if (latest.text.includes(marker.end)) return …              // ① 不可能：END 没执行
  if (sessionStatus.kind === 'exited') return …               // ② 否
  if (result.waitReason === 'stdin_read') return …            // ③ 否：见层 2
  await pause()                                               // 25ms 后再来
}

inferred_idle 不在任何返回分支里 → 每 25ms 空转一轮直到 300s deadline → 走 timeout 分支 → shells.reset() 杀掉整个 shell。

连锁效应（解释现场所有怪象）

• set +H 自救无效：跨调用的 set +H 被 timeout 后的 shell reset 抹掉；同行的 set +H 无效——expansion 发生在读行时，行内语句还没执行；
• 满屏 dsh> ：丢弃行后 bash 停在无标记提示符，后续调用/空轮产生的提示符文本进 scrollback；超时后 partialOutput 找不到 START 标记（整行被丢弃，START printf 也没跑），回退 scrollback 尾部 → 模型只看到一串 dsh> ，真正的错误消息 event not found 被 scrollback 上限截掉（LOST_PREFIX_MESSAGE 正是现场看到的「beginning was dropped」）。

修复方案（B、C 已复现验证通过）

#	层	改法	验证
B	层1	quoteForBash 改用传统单引号引用（'…'＋'\''）替代 $'...'——历史扩展对单引号内容豁免	✅ 全链正常输出
C	层1	shell 初始化序列（:273 stty -echo 处）追加一条 set +H，交互 shell 全程关闭 histexpand——agent 场景本就用不到它	✅ 同上
D	层3	executeCommand 循环对连续 N 轮 inferred_idle 且无输出增长加早退，报文识别 event not found 特征提示模型「命令行被 shell 丢弃，检查 ! 字符」	韧性加固
E	层2	完成检测不能只依赖 PROMPT_COMMAND：inferred_idle ＋ 前台=shell 本身即「回到提示符」	韧性加固

建议：C 一行根治（B 作为纵深防御一起上，注意 $'...' 换 '...' 需保留对 \r/\n 字面量的处理）；D/E 让任何未来的「行被丢弃」类故障快速失败而非烧 300 秒。

附注：本机 PATH 解析到 /bin/bash 3.2.57（macOS 系统 bash），复现与生产行为一致；bash 5.x 上 $'...' 是否豁免 ! 未在本机验证，修复不应依赖版本行为。

[PerryLink]

This is fixed on master, and the fix is not in rc.3.

Commit 967ba4c4b8 ("fix(tools): disable history expansion in the persistent bash shell", 2026-10-21) changes the init send in packages/shell/tool-bash-persistent/src/index.ts from text: 'stty -echo' to text: 'stty -echo; set +H' — your layer 2, in one line, with the comment now naming ! and the discarded wrapper line. There is a regression spec in tests/loader-composition.spec.ts. The commit is an ancestor of master (22ddee3) and not of the dsh-v0.2.1-rc.3 tag (1f81c04, 2026-10-23 11:29), so the rc.3 line never picked it up; anyone on rc.3 still hits this.

Your layer 1 is unchanged: quoteForBash (:74-80) still emits $'...' and still escapes only \, ', \r, \n. After the fix the two layers are no longer independent — set +H is the only thing between ! and event not found. If the init ever stops setting it (a new backend, a different shell, a rewrite of the wrapper), the quoting bug is back. Escaping ! inside $'...', or switching to the '\'' idiom, would make the quoting form correct on its own.

Two details from your report I would keep verbatim, because they are what makes it diagnosable: the marker printf is discarded with the line, so there is no end marker and the tool waits to the deadline; and the post-discard prompt carries no OSC 133;D, so prompt-based completion cannot tell an idle shell from a discarded line.