Claude Code 将 Auto mode 设为默认模式
Auto mode is now the default in Claude Code
从 8 月 14 日起，Claude Code 的 Pro、Max 和 Team 计划将默认启用 Auto mode。这一改变旨在解决开发者对权限提示的“习惯性点击”问题。数据显示，人工审核仅能拦截 13.6% 的危险指令，而 Auto mode 的拦截率高达 89%。通过内置的分类器，系统能在不频繁打扰用户的前提下，自动阻断不可逆或破坏性操作。在独立测试中，开启 Auto mode 的 Claude 模型在提示注入攻击中实现了零成功率的防御表现。Adobe、Nuro 等团队已将其作为生产环境默认模式，并观察到代码提交量提升了约 25%。
在包含 1053 名付费专业测试者的对照实验中，人工审核仅发现了 13.6% 的危险命令，而 Auto mode 拦截了 89% 的同类命令。
HN 评论区
310- awkii
我显然属于那极小的一派用户，过去一年里在每次使用 Claude 时都运行 `--dangerously-skip-permissions`。这对我来说几乎成了本能。大部分情况下 Claude 表现良好，但我绝不会盲目信任它。大语言模型本质上是危险的工具，逐条审查命令（或者狂按 `y`）并不能让它们变得安全。安全责任在于开发者，需要设置合理的护栏（比如版本控制系统、不可变文件系统或只读令牌）。用更多的 Claude 来分类 Claude 命令的安全性，并不是解决办法。
- hmokiguess
除了关于这是否比人工审查“更安全”的争论外，我还有一个略有不同的问题。
当我在手动审查模式下运行 Claude 时，它经常试图做一些并非“危险”但与我的意图不符的事情。也许是我在跟模型较劲，但举个例子，在协调其他代理执行工作时，Claude 非常想过度规定工作如何完成，告诉它们确切要编辑哪些文件、确切不能做什么，而不是信任流程中的护栏、审查代理或人类来捕捉代码层面的错误。而且，不，告诉它别这么做也没用，它记不住。手动审查是我在这里的最后一道防线。
我有一些不想被黑名单禁止的操作，只允许它使用能力有限的工具来指挥代理，并设置各种钩子来尝试捕捉权限系统无法识别的行为。但如果我使用 Auto 模式，我就失去了这种控制。分类器会兴高采烈地批准这类命令，因为猜猜看，它也是 Claude。
- dgunay
“我们在过去几个月测试了自动模式是否与平均用户点击提示一样安全，或者更安全。”
嗯，从他们的角度来看可能说得通，但我不需要。我有时也会点击通过而不读所有内容，但我喜欢保持控制权，了解新代码，并在方向跑偏时进行调整。这只会浪费更多 token，因为我不得不丢弃很多东西。我希望我的手动审批设置在未来的更新中也能得到尊重（否则我就换平台了）。
- lukan
我一直使用 Claude Code 内置的 /sandbox 功能，配置如下：
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"autoAllowBashIfSandboxed": true,
"allowUnsandboxedCommands": false,
"filesystem": {
"allowWrite": [
"."
],
"denyRead": [
"~/*"
],
"allowRead": [
".",
// 还有几个目录
]
}
},
"defaultMode": "auto"
但这感觉还远远不够安全。
运行代理式 AI 的最务实的隔离方式是什么？
我猜是：
1) 在 Docker 容器内运行 harness
2) 将项目文件夹（以及根据开发栈的依赖文件夹）挂载到容器中
3) 在容器外安装依赖（不使用私有注册表密钥）？
4) 在容器外运行 git 命令（不使用 git ssh 密钥）
我是不是漏掉了什么？
- sandcat_
值得提一下，因为我觉得至少有几个评论者把它们搞混了：auto mode 不同于 --dangerously-skip-permissions / YOLO 模式。在 auto mode 下，有一个分类器会在任何命令执行前运行，理论上会阻止任何危险命令的执行。我发现它相当烦人且过于激进，但可能相当有效。
- bsdz
对于那些我不希望与 Claude 过多交互的小型项目，我开始使用 Anthropic 的沙箱运行时工具 "srt"：
https://github.com/anthropic-experimental/sandbox-runtime
这与 "auto" 模式结合使用。
目前看来效果不错。我手动检查了各种事项，如读写权限、敏感文件夹/文件的访问等。
到目前为止，我只在两个小项目上用过它。我的主要项目我一直是在点击提示，最近才切换到 "auto" 模式。
我不太明白为什么有人会信任 "--dangerously-skip-permissions"。我见过这些代理太多次跑偏了，安装不必要的包和环境，调用 sudo，并在各种地方创建文件。
他们的网站上有一页关于各种沙箱策略的说明：
https://code.claude.com/docs/en/sandbox-environments
我在几个话题中看到过各种评论，有人自己构建沙箱。这很好。不过我倾向于先尝试 Anthropic 的解决方案。
- fzxu22
现在这东西脱轨太快、太频繁了，不适合这样做。当然，如果你有 5 个文件的小任务？你在构建一次性原型或概念验证？那就去吧。但如果你有一个真正的项目，期望维护并与他人协作？那么，和任何真正的架构设计说再见吧。目前很难让这些工具构建出可扩展、可维护的代码。这就像让一个初级开发者来设计架构。它可能勉强能用，但看看任何维护或更新发生时的情景吧。你的应用中每个端点都有不同的安全实现，15 份代码没有复用，到处都是死代码，而且完全不知道如何理清它们。当你专心盯着的时候都很难控制这些东西。开启自动模式会让这变得更难。
- prtmnth
在自动模式推出之前，我有一个脚本在每次权限请求前运行，它调用 Haiku，带上一个包含安全和不安全命令示例的提示，让它分类为安全/不安全并记录日志，以便我稍后审查。这对我非常有效，直到自动模式推出，那时我更喜欢使用提供商内置的分类器，而不是维护自己的。
自从该功能发布以来，我一直在使用自动模式。除了极少数分类器阻止了安全命令的情况外，我没有遇到任何问题，并继续将其作为默认模式。太棒了！