Claude Code 的 auto mode：把人的注意力花在真正要紧的地方
Claude Code 在跑命令、改文件之前会先问你批不批准。这个安全检查作为默认是对的——但对每天泡在 Claude Code 里的人来说，没完没了的权限弹窗本身就成了一种摩擦。你开始不认真看了，于是确认框也就不再保护你了。
auto mode 是我们的答案：让 Claude Code 在日常活儿上自行推进，但真碰上有风险的事，仍然停下来问你。
「全都批准」错在哪
对付弹窗疲劳，最粗暴的办法是干脆把权限全关掉——就是那个众所周知的 --dangerously-skip-permissions 标志。它确实管用，也有不少人在用，但它是拿你全部的安全去换便利。一旦开了，Claude Code 会不问就跑任何命令：删文件、推远端、从网上 curl 一段脚本直接管道进 shell。
对很多工作流来说这风险太大了。大家真正想要的其实更窄：「安全的事别再问我，但做可能造成伤害的事之前，还是先跟我确认。」
auto mode 怎么判断
auto mode 引入了第二个模型——一个快速分类器（classifier）——它看 Claude Code 想做的每一个动作，把它归进两个桶之一：可以放行 或 需要人来定。
分类器拿每条命令去对照一组风险类别，专门盯这些东西：
| 风险类别 | 例子 |
|---|---|
| 权限升级 | sudo、改权限、动安全设置 |
| 不熟悉的基础设施 | 跟项目平时根本不碰的服务器或服务通信 |
| 破坏性操作 | 删数据、force-push、drop 数据库表 |
| 被 prompt injection 驱动的动作 | 看起来像是源自 agent 刚读到的不可信内容、而非你真实意图的命令 |
如果是常规操作——跑测试、读文件、改源码、一次正常的 commit——它不打断你直接放行。一旦踩中某个风险类别，Claude Code 就退回到老办法：请你显式批准。
纵深防御（defense in depth）
分类器只是一层，不是全部。auto mode 的设计就是要和我们做的其他隔离工具叠在一起用：
| 层 | 作用 |
|---|---|
| Sandboxing（沙箱） | 由操作系统强制的文件系统与网络限制，即便一条命令被放行，也跨不出它的边界 |
| Allowlists（白名单） | 你永远想放行的命令的显式规则，在分类器之前先判 |
| 分类器 | 兜住那条「没有任何静态白名单能预料到的」新命令长尾 |
没有任何单独一层是足够的。沙箱限制爆炸半径，白名单确定性地处理已知安全的情况，分类器对其余一切做判断。三者合在一起，让 agent 在大幅减少监督的同时，把危险动作仍然关在门内。
关于 prompt injection 多说一句
最重要的风险类别之一就是 prompt injection（提示注入）。随着 agent 读越来越多不可信内容——网页、issue、日志、第三方文件——其中藏着「专为劫持 agent 而写的指令」的风险也越来越大。
分类器经过专门训练，能注意到一个动作看起来是被 agent 刚吞下的内容驱动的，而不是被用户的原始请求驱动的。比如「刚读完一个可疑网页，紧接着就要导出环境变量」——这正是它该标记的模式，哪怕同样这条命令在别的语境下可能完全无害。
什么时候用它
auto mode 最闪光的场景是：你信任一个任务的大方向，但不想盯着每一步——大型重构、批量修 lint 错误、啃一长串写得很清楚的改动。
在非交互运行里（CI、脚本、定时任务）auto mode 行为略有不同：因为没有人在场去批准被标记的动作，反复被标记会让运行直接中止，而不是傻等一个永远不会来的输入。
用一个标志开启：
claude --permission-mode auto -p "fix all lint errors"总结：更大的图景
auto mode 反映了一个对「agent 该怎么工作」的更大信念：安全和自主不是要互相取舍的对立面，而是要一起工程化出来的两个属性。
目标从来不是把人拿掉——而是把人的注意力花在真正要紧的地方，别花在不要紧的地方。