沙箱网络失败伪装成 TLS 错误（建议显式标记）

[sunwindy91]

沙箱拦截出站 HTTPS，但失败表现为 TLS 错误（“基础连接关闭”），而非显式“沙箱拒绝”标记。

Agent 无法区分“网络问题”（重试有效）与“安全策略”（重试无效）——实测同一 URL 重试 3 次全失败。

建议：沙箱网络拒绝返回显式标记（sandbox-denied），与写/执行管控一致。

复现：沙箱受限模式下，用 Invoke-WebRequest 访问任意外网 URL，观察失败信息。

[sunwindy91]

补充：本研究还有另外 4 个实测发现（均带数据，可复现）：

发现 2：归档≠删除 + GUI 无删除入口

实测：GUI"归档"会话后，jsonl 文件原封不动（19,190 字节），仅 archivedSessionIds 逻辑标记；解压后内容完整可读；GUI 无"删除"入口。
影响：用户以为数据已删除，实际 100% 保留且可读——信任基础设施缺口。
建议：① 提供"删除"（区分移除/彻底删）② 归档时明示"数据仍保留" ③ 敏感信息输入时事前提醒。

发现 3：tool/result 的 ok 字段不可信

实测：解压会话 jsonl 统计 218 次工具调用，ok 字段全部 true（名义失败率 0%），但解析 stderr 文本后真实失败率 15.1%。
影响：健康度监控若依赖 ok 字段，会得出"100% 成功"错误结论。
建议：tool/result 增加结构化错误字段（exit_code/error_type/stderr 分离）。

发现 4：崩溃后前端报错误导

实测：服务崩溃时前端报"自动保存失败：failed to fetch"——用户无法区分前后端故障。
建议：前端探活（/health），崩溃时明确引导"服务未运行，请重启"。

发现 5：大依赖目录拖慢工具扫描

实测：工作区含 node_modules（5,851 文件/435.7MB）时首次全树扫描 29s（占单轮 65%）。
建议：搜索工具支持忽略规则（node_modules/.git 排除）。

[sunwindy91]

补充：本研究的配套产物已开源，供参考（不仅测试，还构建了可运行实现）：

• 白小纯修仙工具插件（Cordis 插件：灵签/灵气/修为）：
  https://github.com/sunwindy91/dsh-tool-baixiaochun
• 桌面壳 + 白小纯桌宠（Electron）：
  https://github.com/sunwindy91/dsh-desktop-shell
• DSH 插件开发方法论（Cordis 插件 6 个实测要求）：
  https://github.com/sunwindy91/dsh-plugin-methodology

其中插件已在本机 DSH 环境实测可用（工具成功进入会话工具列表）。

[zoahdev]

核验你的三项发现（对照 main HEAD 99f6f02 rc.7），都有源码支撑，第 3/5 项可以再精确一点：

发现 2（归档≠删除）：成立，且是有意的标记设计。 packages/workspace/workspace/src/index.ts:244-256 的 archiveSession 只把 id 追加进 archivedSessionIds（setState 写注册表状态），全程没有文件删除/移动；workspace.spec.ts:882-895 的测试还明确钉住"归档后 registry 只多一个 id 标记"。你的实测（jsonl 19190 字节原封不动）与设计一致。"数据仍保留"确实应该对用户明示——建议补一条归档动作的 UI/文案提示，或至少在 README 说明归档与删除的区别。

发现 3（tool/result 无可靠 ok 字段）：成立，但字段名要说准。 tool/result 事件 schema（packages/core/session/src/types.ts:291-300）只有可选 error?: { name; code }（内部失败）和可选 isError（packages/llm/llm/src/types.ts:88-94 的 ToolResultBlock）——没有强制、结构化的语义失败字段。你在日志里统计的 ok 是工具私有 payload（meta/content），不是 session schema 字段，所以"100% ok"是测量盲区。你的建议（exit_code/error_type/stderr 结构化）正好补这个缺口；最小做法是让 shell 类工具在 isError 上做归一（exit≠0 → isError:true），健康监控再按 isError/error 统计，而不是解析 stderr 文本。

发现 5（node_modules 被扫）：成立，而且是 glob 路径的显式设计，还有个工具间不一致值得注意。 packages/fs/tool-fs-search/src/glob.ts:83-112：buildGlobCommand 固定带 --no-ignore --hidden（故意搜索忽略+隐藏文件），只排除 VCS 元数据目录（.git/.svn/.hg/.bzr/.jj/.sl，glob.ts:38）——node_modules 不在排除列表，29s/435MB 是设计后果。而同一个包的 grep（grep.ts:112-120）不带 --no-ignore，走 ripgrep 默认（尊重 .gitignore）。也就是说：glob 无视 .gitignore、grep 尊重 .gitignore，同一 workspace 两个搜索工具语义不一致。建议：要么给 glob 加可配置排除列表（默认 node_modules/dist/build，同时保留 --hidden），要么把 glob/grep 的 ignore 语义统一并写进 README 的 Known Limitations。

发现 1（TLS 伪装）： 与 #3207 同族，我已在那边回复 Windows 沙箱 schannel 失败链路，不重复。发现 4（前端误导性报错）属于 UI 层，值得单独开帖给前端探活建议（/health 心跳 + 崩溃引导），这边先不展开。

[sunwindy91]

发布稿A_回帖3182.md

[sunwindy91]

请问回帖的md文件有收到吗？