哪些工具调用被拦了：OpenTelemetry 新事件 claude_code.safety_event

团队里推广 Claude Code 一段时间后，管理员常会被问到两类问题：「我们的权限规则到底有没有起作用？」和「为什么它老是停下来问我？」。以前要回答，只能翻个人终端里的记录，或者让同事截图。

CLI 2.1.307 在 OpenTelemetry 里加了一个专门的事件：claude_code.safety_event。

它记录什么

按更新说明的写法，每一次工具调用只要被下面任意一种机制「拦下、改为询问、或退回给 Claude」，就会产生一条事件：

来源	典型场景
权限规则	`deny` / `ask` 规则命中某条 Bash 命令或某个文件路径
auto mode	自动模式的分类器判断这一步需要确认或不该执行
安全检查	内置的安全检查认为命令有风险
钩子（hook）	`PreToolUse` 等钩子返回阻止或要求确认
沙箱	沙箱策略不允许这次访问

三种结果分别对应「stopped」（直接拦下）、「prompted」（停下来问人）和「sent back」（把调用退回给 Claude，让它换个做法）。

换句话说，它记录的不是「所有工具调用」，而是安全层真正出手的那些时刻。

1. 规则是不是写对了

一条 deny 规则上线后，如果一周里从没出现过对应的 safety_event，要么大家根本没碰到那类命令，要么规则写得太窄没匹配上。反过来，某条规则每天触发几百次，往往说明它挡住了正常工作，值得调整。

2. 「老是弹确认」到底是谁弹的

用户抱怨打断太多时，按来源聚合一下就能看出是权限规则、auto mode 分类器还是某个团队钩子造成的，排查方向一下子清楚了。

3. 审计留痕

对有合规要求的团队，「哪些危险操作被系统挡掉了」本身就是需要留存的记录。以前这类信息散落在各人本地，现在可以和其他遥测一起进集中存储。

前提和其他 Claude Code 遥测一样：先打开 OpenTelemetry 导出并配置好 OTLP endpoint（具体变量以当前版本官方文档为准）。之后在 collector 或后端里把 claude_code.safety_event 这个事件名加入采集和映射即可。

事件里具体带哪些属性（比如来源、结果、工具名的字段名），更新说明没有逐一列出。建议升级后先在测试环境里触发几次已知会被拦的操作，看清实际字段再写仪表盘查询，不要凭猜测建表。

站内之前介绍过 api_request 事件里的缓存写入字段，两者可以放在同一套看板里：一个看成本，一个看安全层的干预频率。

2.1.307 还修了 /permissions → Recently denied（最近拒绝） 的两个问题：

现在批准某一行时，界面会写明具体命令而不是一段描述，批准也会被分类器正确认到。配合 safety_event 一起看：遥测告诉你哪里被拦得多，本地用「最近拒绝」逐条放行真正需要的命令。