作者：simon · 2026-10-18
我数了一下。
从 2026 年 9 月 18 日到 10 月 13 日，不到一个月，agent 的权限分类器一共拦了我 27 次。
先说结论
- 27 次，分布在 10 个不同的日子，12 种拦截标签。
- 其中至少 7 次拦的是只读命令：查账号信息、看机器详情、读文件、
grep。 - 其余的，绝大部分是真的会改东西的操作：改生产 CloudFront 配置、批量删线上页面、部署、停用密钥、改 DNS。
- agent 每次被拦都是同一个反应：停下来说明，把命令写好交给我，不绕过。
我是怎么数的
我没有记账，是事后从自己的会话记录里数的：
- 统计工具返回里所有的
denied by the Claude Code auto mode classifier. Reason: [标签]； - 按每一次工具调用去重；
- 剔除了 4 条：那是我在一个会话里读另一个会话时，引用到的拦截文字，不是真拦截；
- 同一时间、同一标签、同一命令的会话副本，合并成一次；
- 只统计了 9 月 18 日以后的会话，更早的没有查。
标签分布
| 标签 | 次数 |
|---|---|
| Modify Shared Resources | 6 |
| Production Deploy | 6 |
| Cloud Storage Mass Delete | 4 |
| Interfere With Workloads | 2 |
| Credential Materialization | 2 |
| 其他 7 种（各 1 次） | 7 |
其他 7 种是：Credential Exploration、Secret-Store Writes、Protected-Scope IaC Apply、Blind Apply、DNS / Domain / Cert Changes、Irreversible Local Destruction、Unrequested Commit in a Connected App。
第一类：该拦的，而且拦得有用
批量删线上页面。 10 月 13 日，agent 要把四个下线语言的页面从线上删掉。它事先列出了这几个前缀下的对象：正好 16 个，没有别的。然后命令被拦了（Cloud Storage Mass Delete），它把命令交给我，我手动执行，之后验证了这些地址返回 404、其他页面正常。
改生产的 CloudFront 配置。 9 月下旬到 10 月，同一类动作被拦了好几次（Modify Shared Resources），都是改分发配置、挂一个函数。每次它都把补丁配置准备好，让我在终端里自己跑。
重建 DNS。 10 月 13 日上午，agent 判断"托管区全没了"，要新建托管区、重写整套记录。命令被拦（DNS / Domain / Cert Changes），它改成写脚本让我执行；脚本在中途因为"记录已经存在"报错，才发现托管区一直都在，是它判断错了。（完整经过见我另一篇，写账单的那篇。）这一次的拦截，替那个错误的判断多争取了一次人工检查。
第二类：只读也被拦（至少 7 次）
我把 27 次逐条过了一遍，下面 7 次，命令本身只是查询或读文件：
| 日期 | 标签 | 做的事 |
|---|---|---|
| 9 月 18 日 | Credential Exploration | 查询账号信息 |
| 9 月 18 日 | Interfere With Workloads | 查看被入侵时攻击者那两台机器的详情，留证 |
| 10 月 13 日 | Credential Materialization | 读本地配置里密钥的前几位（脱敏显示），列出 profile，查当前身份 |
| 10 月 13 日 | Credential Materialization | 在本地配置里 grep 密钥 ID，看 git 日志，列出 profile |
| 10 月 13 日 | Interfere With Workloads | curl 取一个公开地址的缓存副本 |
| 10 月 13 日 | Production Deploy | grep 读部署脚本里的某一行 |
| 10 月 13 日 | Unrequested Commit in a Connected App | 读我已登录的发文平台的编辑页结构 |
其中两条碰的是凭证文件。我觉得这两条先问一句，是有道理的：它们读的是 .env，哪怕只是前几位。
其余 5 条，我自己的判断是偏保守。尤其是表里倒数第二条：一条 grep，被贴上了"生产部署"的标签。 标签和命令对不上。
另外有一条值得单独说：9 月 18 日我在应急取证，攻击者的机器还没处理完，"看一眼实例详情"也被拦了一次。应急的时候，每多一次中断，就是多一次要我停下来手动执行。
agent 被拦之后怎么做
27 次里，我看到的反应是一致的：
- 停下，说明被拦的是什么、标签是什么；
- 不换个写法再试；
- 把能直接粘贴的命令交给我，让我用
!前缀在终端里自己执行； - 之后验证结果。
拦截信息里自带了一句话：
To allow this type of action in the future, the user can add a permission rule for Bash to their settings.
意思是：如果你认定某类操作可以放行，可以去设置里加一条规则。
如果是我来配
这几条来自上面的数据，是建议，不是官方做法；具体的规则语法，请以官方文档为准，我这次没有去核对。
- 只读类的命令（describe、list、get、
grep、cat之类）：可以考虑放行。这是 27 次里能省掉 7 次的部分。 - 会改东西的（删、改分发配置、部署、改 DNS、停用密钥）：继续留着拦截。它们是 27 次里的大头，也是出事时代价最大的。
- 凭证文件：读之前问一句，我觉得合理。
- 自己做记录：我是事后从会话记录里数的。如果能在被拦时顺手记一笔，复盘会容易得多。
局限
- 只统计了 9 月 18 日以后的会话，更早的没有数据。
- "只读 / 会改"是我逐条看命令后的归类，不是分类器的结论；其中几条（比如几次批量操作 S3 对象的）我没有逐条核对命令全文，没有算进"只读"。
- 分类器内部怎么判断，我不知道，只能看到标签。
- 我没有统计"被拦后我手动执行了几次"，也没有统计每次耽误了多久。
参考与出处
- 作者本机 2026-09-18 至 2026-10-13 的 Claude Code 会话记录（统计方法与逐条表见
notes/2026-10-15-classifier-blocks.md）。 - 拦截信息中的一句英文引用，来自会话记录里工具返回的原文。
