Hermes 修了一个细但很重的安全规则：沉默不是同意
Hermes PR #24923 修的是一个所有涉及不可逆操作的 Agent 都该关心的 clarify-tool timeout 行为。过去 CLI callback 在用户超时未回复时，会把一句 “Use your best judgement to make the choice and proceed” 返回给模型。对于权限确认类问题，这可能被模型理解成允许执行，PR 里直接点名了 `rm -rf .git` 这类破坏性操作。修复把 timeout 文案改成明确拒绝，并在 tool description 里提前告诉模型：超时不是授权。同期 Hermes 还在补几条运维边界：#24925 让 session_search 只加载 FTS 命中附近窗口，而不是先读完整 800+ 消息会话；#24927 追踪写文件成功但因 diagnostics 里有 error 字样而被误判失败的问题；#24928 在 Windows terminal subprocess 前清理继承的 Python 路径；#24930 修 root / AppArmor 受限环境下 browser 启动 flags 被忽略的问题。
影响风险 来源3 对象operator · developer · team
审批交互本身就是安全基础设施。一个在聊天里看似无害的 timeout 文案，如果被塞回模型后等同于“用户允许”，就会变成 policy bug。它提醒我们：Agent 安全不只取决于有没有 approval tool，也取决于工具把什么话返回给模型。
- PR #24923 说明 clarify timeout 曾返回 “Use your best judgement to make the choice and proceed”，并改为对破坏性或不可逆操作的明确拒绝
- 该 PR 增加 tests/tools/test_clarify_tool.py 回归测试，并区分 gateway callback 与 CLI callback 行为
- PR #24925 把 session_search 从加载完整对话改为 FTS5 命中窗口，提到 866-message session 可降到每个 match 约 11 条消息
- Issue #24927 说明 write_file / patch 已成功但 nested diagnostics 含 error 文本时，可能被误判为 mutation failure
- PR #24928 与 #24930 分别处理 Windows terminal Python 环境泄漏，以及 browser --no-sandbox flag 注入失效
- 核心 clarify 修复仍是 PR，部署侧要等合并发布或自行打补丁
- non-interactive oneshot 行为刻意不同，操作者需要验证自己的实际入口
- timeout 语义改变会让部分流程从继续变为停止；这更安全，但可能需要更清晰的用户提示