内置 glob 在 Windows 权限墙下整单作废：exit 2 连同已扫到的结果一起丢弃，模型易把「失败」误读成「不存在」

[Ronniealgo]

环境

• DeepSeek Harness 桌面版 0.2.0-rc.2，Windows 11，desktop profile
• 内置 glob 工具（委托 ripgrep）

现象

对含系统 ACL 目录的树（C:\Program Files 最典型：ModifiableWindowsApps、WindowsApps 等对普通进程拒绝访问）做搜索时，ripgrep 以 exit 2 结束，glob 工具将整次搜索判为失败，已扫到的全部候选一并丢弃，模型只收到：

Error: glob search failed (exit 2): rg: ... 拒绝访问。 (os error 5)

为什么这是真问题

下游模型把「搜索失败」和「没找到」混为一谈的倾向很强：一次因权限失败的搜索，很容易被顺势总结成「该文件不存在」。我在实际使用中已多次遇到这种假阴性。

复现步骤

1. 让 agent 用内置 glob 在 C:\Program Files 下找 *.exe
2. 树里实际存在大量可读结果（如 C:\Program Files\AntiCheatExpert\ACE-Service64.exe），但返回的只有上述 Error，部分结果不随附
3. 追问模型「这个文件到底在不在」，大概率得到「不存在」的错误结论

期望行为（建议）

把「部分成功」作为一等结果暴露给模型，例如：

• rg 以 exit 2 结束时，返回已扫到的匹配，并附带 skipped: [{path, code}] 与 complete: false 之类的覆盖标记
• 只有 complete: true 且零匹配才等价于「确定不存在」
• 若一次性改动太大，至少在 Error 文本里附上已收集的部分结果，避免信息全丢

参考实现

我们按上述语义做了一个最小插件（MIT，Ronniealgo/dsh-find-file）：跳过权限墙、如实上报 skipped/complete、symlink/junction 不跟随防循环，31 项单测全绿。结果结构可供官方参考。

[Ronniealgo]

勘误：正文说 31 项单测，实际全量是 36 项——最初统计漏了 CLI 套件的 5 项（它们要拉起子进程，在当时的开发沙箱里跑不了；正常环境与 CI 无碍）。修正后 36 项在 Node 20 / 22 / 24 与真实 Windows runner 上全绿。

[PerryLink]

先确认结论：属实，而且我实测下来，被丢掉的不是"可能有一点"的残片，是一大批真实结果。

版本基线

你写的是 0.2.0-rc.2。当前 npm 上 latest = next = 0.2.0-rc.2，alpha = 0.2.1-alpha.2；我核对的是 origin/master（= dsh-v0.2.1-alpha.2）。结论在新线上同样成立，不是旧版遗留。

丢在哪一步（三行，顺序就是因果）

packages/fs/tool-fs-search/src/search-core.ts：

• :268 —— stdout 其实已经读出来了：const stdout = handle.collected.stdout?.readFrom(0)
• :282-283 —— 紧接着按退出码判死：if (outcome.exitCode !== 0 && outcome.exitCode !== 1) throw classifyRunFailure(...)
• :285 —— 解析入口 completeStdout(...) 在抛错之后，永远走不到

也就是说，那一批已经躺在内存里的路径，是被 :283 这一行扔掉的。同文件 :201-202 的文档注释把这套语义写成了契约："exit 0 is success with results, exit 1 is success with zero results (noMatches), anything else throws a SearchError" —— 这就是为什么"部分成功"目前没有表达位置。

你贴的文案也对得上，出自 :129：`${toolName} search failed (exit ${exitCode})${stderr.length > 0 ? `: ${stderr}` : ''}`。

我在本机实测了一遍（这条最关键）

参数就是 buildGlobCommand() 的原样（glob.ts:89-107）：--files --glob=*.exe --sort=modified --no-ignore --hidden <VCS excludes> -- "C:\Program Files"。环境：Windows 11，@vscode/ripgrep-win32-x64@1.18.0（rg 15.0.0）。

• 唯一的墙是 C:\Program Files\WindowsApps → os error 5（拒绝访问，普通进程无法列目录）
• 结果：exit code = 2，stdout = 641 行

所以"部分结果拿不到"这个直觉可以排除：数据是现成的，不需要改 ripgrep 的任何参数，只要改退出码策略。这一点值得先钉死，否则容易被人以"rg 报错就是没输出"为由挡回来。

这不是 glob 独有的：grep 同缺陷，而且「exit 2」不止一种

两个工具共用同一个 runRipgrep（glob.ts:338、grep.ts 同构），所以 grep 也丢部分结果。这一点值得写进诉求，因为修复必须区分两类 exit 2：

• 部分成功（你遇到的：权限墙 + 有结果）
• 用法错误（search-core.ts:126-127 的 pattern/glob 解析失败 → SEARCH_INVALID_PATTERN；不存在的 target 也会给 exit 2）

如果只是「exit 2 就返回部分结果」，那 ( 这类真错误会被静默变成「0 结果」——比现在更危险。所以判据应该是「exit 2 且 stdout 非空」，并且 SEARCH_INVALID_PATTERN 仍走错误路径。

三条会影响修复形态的实测观察

1. 不要动 --sort=modified。我怀疑过它会让 rg 先缓冲整棵树再输出，于是做了 A/B：带它 641 行，不带它也是 641 行。它不吞部分输出。
2. 不要用 --no-messages 去消音。同样场景下我加了它，exit 仍是 2，而 stderr 变成 0 行——诊断信息没了。stderr 是这里唯一的诊断来源（stderrMaxBytes 已经是保留上限），消音只会把"失败"变成"没有理由的失败"。
3. --no-ignore --hidden 是有意的（glob.ts:94-95，让结果覆盖被 ignore/隐藏的文件），它只是顺带提高了撞上 ACL 墙的概率。修复点应落在退出码策略上，不要退回 ignore 语义。

关于你建议的形态：仓库里已有现成表达可复用

complete: false + skipped[] 不需要新造一套语义。超帽路径已经有"这不是完整结果，这是恢复入口"的完整写法：

• glob.ts:25 GLOB_MAX_RESULTS = 100
• glob.ts:205-239 formatGlobPage / formatGlobOutput：渲染有界分页 + 附 recovery 路径
• glob.ts:226 甚至已经会写 "The complete result could not be saved; narrow pattern or path to see more."

把部分成功接在同一处渲染上，语义一致、改动面最小；skipped: [{path, code}] 则正好对应 stderr 里那几行 rg: <path>: IO error ... (os error N)（可从 :269 已读出的 stderr 解析，且已被 stderrMaxBytes 限长）。

最要紧的一条我同意你的判断，而且它比"少看到几个文件"严重：complete: false 必须是这个结果的一等字段，因为模型对"搜索失败"和"没找到"的混淆倾向确实很强，而这正是假阴性的来源。

你正文里的 36 项单测（含你后来勘误的 CLI 5 项）里，如果有针对 skipped/complete 的断言结构，贴出来可以直接当作上游契约草案——这块目前上游是空白。

[Ronniealgo]

感谢复核与实测——尤其「exit 2 且 stdout 非空」这个判据和「grep 同病」的扩展。dsh-find-file（https://github.com/Ronniealgo/dsh-find-file）在工具层实现了同一套语义（不经过 rg、直接 walk，天然绕开退出码问题），complete/skipped 是一等字段，36 项单测覆盖。你要的断言结构如下，可直接当上游契约草案：

1) 面向模型的 JSON 契约

matches: string[]; matchedCount: number
skipped: { path, code }[]   // 逐条 errno（EPERM/EACCES…），最多留 30 条
skippedCount: number        // 真实总数，可大于 skipped.length
complete: boolean
incompleteReason: "permission-denied" | "time-budget" | "result-limit" | "depth-limit"
dirsWalked / symlinkSkipped / elapsedMs / limits

2) 许可规则（与你的判断一致，这是反假阴性的核心）

• 仅当 complete===true && matchedCount===0 才许可「该 root 下不存在」；
• complete===false 时无论多少匹配，文本必带 INCOMPLETE (<reason>) … NOT proof of absence；
• 工具文本永远以 VERDICT 行收尾，三个分支固定文案（断言见下）。

3) 关键断言摘录（test/walk.test.mjs / test/tool.test.mjs）

// 权限墙：兄弟目录继续搜，跳过条目带 errno
r.skipped[0].code === "EPERM"; r.skipped[0].path.endsWith("locked");
r.complete === false; r.incompleteReason === "permission-denied";
//   且墙外目录里的匹配仍在 matches 里
// 截断：skippedCount=40 而 skipped.length=30（计数不撒谎）
// 假时钟→"time-budget"；超上限→"result-limit"；
//   恰好等于 maxResults 仍是 complete=true（不误报残缺）
// 过深→"depth-limit"；symlink 不跟随、不破坏 complete
// root 不存在 / 未知参数 → reject（错误路径，对应你说的 SEARCH_INVALID_PATTERN 一侧）
// render：/INCOMPLETE \(permission-denied\)/、/NOT proof of absence/、/R\/locked \(EPERM\)/、
//   complete+0 → /does not exist under this root/

4) 与你的判据对齐

• 「用法错误」与「部分成功」分两层：CLI 退出码 0/1/2（完成/致命/用法）；工具层 root/参数错误直接 reject——与你「exit 2 且 stdout 非空→部分，INVALID_PATTERN→错误」同构。
• skipped 与 rg stderr 的 rg: <path>: IO error ... (os error N) 一一对应，从已读出的 stderr 解析即可（即你定位的读取点之后），stderrMaxBytes 限长够用。
• 渲染上 skipped 明细与 complete 标志挂在结果尾部，与现有「超帽分页 + recovery」同一处渲染，语义不打架。

这套语义已在 Node 20/22/24 + Windows runner 全绿，欢迎直接取用；上游落地后若签名有出入，插件按上游为准适配。