【BUG】持久化 bash 工具偶发卡死 300 秒——PTY 交互 shell 进入 readline 补全等待状态时无人应答

[baosfeng]

问题概述

内置的持久化 bash 工具会随机卡死满 300 秒（timeoutMs: 3e5），随后强制重置 shell。卡死与所执行的命令内容无关——一条纯 sleep 3 的命令链也卡死过，同一条 git status 一次 2 秒完成、另一次卡满 300 秒。git 本身完全正常（在非交互 bash -c 中不到 2 秒完成）。

环境信息

• macOS 26.5.2（arm64）
• @deepseek-ai/dsh 0.1.1-rc.2（npm 全局安装）
• Shell：/bin/bash 3.2.57(1)-release（macOS 自带，即 DEFAULT_BASH_SHELL），以 --noprofile --norc -i 启动
• 相关包：packages/shell/tool-bash-persistent、packages/terminal/terminal-bash

现象描述

卡死时，捕获到的部分输出包含：

Display all 1739 possibilities? (y or n)
... <PATH 下 1739 个可执行文件的列表> ...
dsh> bash: syntax error near unexpected token `)'

即交互式 bash（readline）进入了补全等待状态，阻塞在 stdin 上等待用户回答 y/n（或输入流被错误解析）。工具侧从不应答该提示，结束标记永远无法出现，调用只能等到 300 秒超时：

Your command timed out after 300 seconds or experienced an OOM error. Below is partial output: … The persistent bash shell was reset …

观测要点：

• 失败是概率性/状态相关的：相同命令有时成功、有时卡死。只含 echo + sleep 3 + echo 的命令链卡死过；同一句 git status --porcelain 后台执行约 2 秒完成，但此前一次调用卡了 300 秒。
• 较长、含引号/特殊字符的命令（如 git add … && git commit -m "…"）触发概率更高，因此看起来像"git 坏了"，但实际上与 git 无关。
• git 本身健康：后台 git status 2 秒完成；bash --noprofile --norc -c 'git …' 约 1 秒完成。

复现方式

反复多次调用 bash 工具执行含引号/特殊字符的长命令（如 git add），观察是否出现 300 秒卡死及 Display all ... possibilities? 提示。

根因分析（源码层面）

dsh-tool-bash-persistent/lib/index.js：

• wrapCommand() 将命令包装为 printf '%s\n' 起始标记; eval -- $'…'; __dsh_persistent_bash_status=$?; printf '%s%s\n' 结束标记 "$__dsh_persistent_bash_status" 作为单行写入 PTY。
• executeCommand() 随后每 25ms 轮询 scrollback 查找结束标记，直到 deadline(…, config.timeoutMs=300000) 到期。代码里虽有 waitReason === "stdin_read" 的快速返回分支（约第 300 行），但显然没有覆盖本场景：当 readline 显示 Display all 1739 possibilities? (y or n) 时，shell 阻塞等待应答，startSend().done 无法进入任何被识别的状态，循环空转到超时。
• 超时后整个持久 shell 被强杀（shells.reset），所以每次卡死都会丢失 shell 状态（cwd、导出变量等）。

dsh-terminal-bash/lib/index.js：

• DEFAULT_BASH_ARGS = ["--noprofile", "--norc", "-i"]——shell 以交互模式运行，readline 启用。
• 启动时只发送 stty -echo，没有其他 termios 加固（ICANON/IXON/IXOFF/raw 模式均未处理），readline 的字节流处理完全暴露给调用方命令文本中的字节内容。
• 就绪协议依赖 dsh> 提示符（CONTROLLED_PROMPT），因此直接去掉 -i 会导致会话初始化失败。

期望行为

• 工具应检测并自动应答 readline 提示（Display all N possibilities? (y or n)、--More-- 等），或
• 命令应以不会卡死交互 shell 的方式执行（例如每条命令通过非交互 bash -c 子进程运行并同步持久状态，或使 shellArgs 可配置并配套就绪协议），或
• 至少：检测到 stdin 等待时主动发送中断/应答，而不是干等满 300 秒。

建议修复方向

1. 在 LocalSendOperation/executeCommand 中检测输出中的补全等待提示，自动向 PTY 写入 y\n（或 Ctrl-C）。
2. 启动时做 termios 加固（如 stty -echo -icanon min 1 time 0、禁用 IXON），降低交互 readline 下输入流被破坏的概率。
3. 重新考虑是否应默认以交互式 -i 模式作为脚本化命令执行的后端。