Claude Code v2.1.295：钩子终于能「失败即封闭」，护栏不再是摆设

要点速览

• 同一天两个版本，性质完全不同：v2.1.294 是只有两条条目的安全热修，v2.1.295 是 143 项变更（89 项修复）的大批量收敛。
• v2.1.294 修的是「护栏失效」：官方原文 「Fixed prompt and agent hooks written as instructions (such as "Block commands that...") allowing what they should block」——用自然语言描述写成的钩子，此前会放行它本该拦下的动作。
• v2.1.295 新增 onFailure: "block"：命令与 HTTP 钩子可声明「启动失败 / 超时 / 退出码异常时阻断动作」，而不是像此前那样静默跳过检查、让动作照常执行。
• 终端状态协议 OSC 7501：支持该协议的终端可直接显示 Claude Code 是「在工作中 / 等你输入 / 已完成」。
• MCP 侧一批：工具描述长度上限从 2,048 提到 16,384 字符；远程 MCP 断线后不再连不上、也不再对「连上就断」的服务死循环重连。
• 无人值守场景新增 CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS：给 429 / 529 的重试等待设上限。
• 口径声明：Claude Code 官方 CHANGELOG 的版本标题下不标注发布日期，本版日期 2026-10-08 取自第三方发布汇总站的标注，CHANGELOG 与 GitHub Releases 均未给出厂商公布发布日，非官方公布日期。

v2.1.294：一条会让安全策略形同虚设的 bug

这版只有两条，但都指向同一件事——钩子在按「自然语言指令」而不是「结构化判定」写的时候，判断会失效：

Fixed prompt and agent hooks written as instructions (such as "Block commands that...") allowing what they should block

Improved how prompt hooks on Stop and SubagentStop written as instructions (such as "Carry on if the build is broken") are judged, so Claude is less likely to stop early

为什么这条值得单独写一篇：很多团队的护栏是用大白话写的——「拦掉危险命令」「如果构建挂了就继续」。这类写法的好处是直观，代价是判定要靠模型自己理解。在 2.1.294 之前，它可能把「应该拦下」判成「放行」——也就是说，你在配置里清清楚楚看到一条拦截规则，而它实际上没有生效。

这不是「少了一个功能」，是安全控制的静默失效：日志里不会报错，界面上不会提示，只有当你真的触发那条规则时才会发现它没拦住。

v2.1.295：从「失败即放行」到「失败即封闭」

v2.1.295 里最值得关注的一条，官方原文：

Added onFailure: "block" for command and HTTP hooks: a hook that can't start, times out, or exits with an unexpected code blocks the action instead of letting it through

它改变的是一个默认语义。 在此之前，钩子的失败模式是 fail open——钩子自己起不来（./check.sh 不存在、没执行权限）、超时、或者退出码不是预期值，那么它本该执行的检查就被跳过，动作照常发生。对于「拦密钥泄露」「拦危险命令」这类护栏，这等于：护栏越是关键，失效时的后果越严重。

加上 onFailure: "block" 之后变成 fail closed：

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "./check.sh", "onFailure": "block" }]
    }]
  }
}

这两版合起来是一条清晰的产品态度：把钩子当作真正的执行控制点，而不是「尽力而为的建议」。对已经在用 hooks 做企业策略管控的团队，这两版建议一起升、并做一次回归。

其他值得记的条目

对开发者的影响

1. 用 prompt / agent 钩子做拦截的，升到 2.1.294+ 并回归一次。 重点回归「用大白话写」的那些规则——别只测结构化输出的那些，失效的正是前者。
2. 把护栏钩子显式加上 onFailure: "block"。 判断标准很简单：这条规则如果没执行，后果你能不能接受？ 不能接受的全部加上。拦危险命令、拦密钥泄露、拦越权路径，都在这一类。
3. 跑无人值守 / 定时任务的，设 CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS。 429 退避不设上限时，最容易出现的情况不是失败，而是任务堆积——上一个还没放弃，下一个已经启动。
4. 升 2.1.295 后 MCP server 的行为可能变化：工具描述变长意味着更多内容进入模型上下文（成本与注意力都要算），同时也意味着工具描述本身作为不可信输入的面变大了——自建 MCP server 的要确认描述里没有可被注入利用的内容，详见 提示注入。

AI 之家 观点

这两版真正的信号不在任何一个具体功能，而在钩子（hooks）的产品定位变了。

过去一年里，各家 Agent 工具的钩子基本被当成「自动化触发器」——改个提示词、发个通知、记个日志。在这种定位下，fail open（失败就放行）是合理的：钩子挂了不该让整个工作流停摆。但当企业开始用钩子做安全与合规管控时，fail open 就成了致命缺陷——一个拦截规则最可能失效的时刻，恰好就是它最该生效的时刻（攻击者触发它、或它自己出错）。

v2.1.294 修的「自然语言钩子会放行」和 v2.1.295 加的 onFailure: "block"，合起来就是把钩子从「尽力而为的自动化」推向「可依赖的执行控制点」。这个转向对做平台工程的团队意义很大：你终于可以把关键拦截策略真正交给工具，而不只是写在规范文档里。

但要提醒一句，fail closed 不是免费午餐：钩子一旦变成硬门禁，它自身的可用性就变成了整条链路的可用性——./check.sh 文件丢了、脚本有 bug、网络抖动导致超时，都会直接卡住所有人的工作。所以正确的落地姿势是：只对真正的硬管控加 onFailure: "block"，并给这些钩子配监控与告警。护栏变成硬门之后，它自己也需要被监护。

另一条值得单独说的是 MCP 描述上限从 2,048 放宽到 16,384。放宽是好事（长描述此前会被截得没法用），但它同时放大了一类风险：工具描述是模型会读的不可信输入。当 MCP server 来自第三方、描述长达上万字符时，这段文本本身就是一条注入通道。描述变长 = 攻击面变大，这条应该写进接第三方 MCP server 的 checklist。

待核实

• v2.1.294 / v2.1.295 的厂商公布发布日：官方 CHANGELOG 与 GitHub Releases 均未提供，本文的 2026-10-08 来自第三方发布汇总站标注，待与官方口径核对。
• OSC 7501 的终端支持清单：官方条目只说「实现了该协议的终端」，本站未逐款终端实测，iTerm2 / Ghostty 系为举例而非官方列举。
• onFailure 的其他取值：官方条目只明确了 block，是否存在其他取值（以及默认值是什么）本站未在 CHANGELOG 中读到明确说明，务必以官方文档的 hooks 章节为准。

来源

• Claude Code 官方 CHANGELOG（Anthropic，v2.1.294 / v2.1.295 原始条目，本文全部引文出处）：https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
• Claude Code 官方文档：https://code.claude.com/docs/en/overview
• 相关：Claude Code 工具卡 ｜ 提示注入 ｜ MCP