Claude Code 自动模式将于2026年8月14日成为默认
2026年8月14日起,Claude Code Pro、Max和Team新会话默认启用自动模式。了解6种权限模式、v2.1.200别名,以及无人值守VPS应如何选择。
2026 年 8 月 14 日自动模式会有哪些变化
Claude Code 自动模式会直接运行工具调用,不会停下来询问您,并且会先将每项操作发送给单独的分类器模型进行审核。从 2026 年 8 月 14 日起,Pro、Max 和 Team 计划的新会话将默认使用此模式。您可以随时切换模式,已经为自己设置的默认模式不会被覆盖。
文档对此的说明如下:
从 2026 年 8 月 14 日起,自动模式将成为 Pro、Max 和 Team 计划中新会话的默认权限模式。您可以随时切换模式。除非您接受一次性切换提示,否则自行设置的默认模式会保持不变;由组织管理的默认模式也不会改变。
其中有两个条款比日期更重要。您在自己的设置文件中设置的 defaultMode 会在此次变更后保留。组织通过托管设置部署的默认模式也会保留。公告文章还说明,在此次发布的初期,Enterprise 计划以及使用 API 的账户仍可选择是否使用自动模式。
如果您在 VPS(虚拟专用服务器)上运行 Claude Code,那么在变更生效前了解这些内容很有必要。权限提示是需要有人操作键盘的检查点。您通常不在远程服务器旁,因此会话启动时使用的模式,可能就是它连续运行数小时所保持的模式。
Claude Code 权限模式:从监督最严格到最宽松
共有 6 种模式。每行开头的名称就是您在设置中填写或传递给 --permission-mode 的值。
default:Claude 每次使用新工具前都会请求确认。在工作目录内读取文件仍会直接执行,不会提示。CLI(命令行界面)将此模式标记为 Manual,并从 Claude Code v2.1.200 起接受manual作为别名。plan:Claude 会读取文件并运行命令进行探索,但不会修改源代码。您批准计划前,编辑操作会被阻止。acceptEdits:文件编辑会直接执行,同时文件系统命令mkdir、touch、rm、rmdir、mv、cp和sed也会直接执行。此规则仅适用于工作目录或additionalDirectories内的路径。其他所有 shell 命令仍会请求确认。auto:所有操作都会执行,但分类器会先检查每个操作。明确的ask规则仍会强制请求确认。dontAsk:Claude Code 会自动拒绝所有原本需要请求确认的操作。只有您的allow规则、内置的只读 Bash 命令,以及由PreToolUsehook 批准的调用会执行。会话不会等待输入。bypassPermissions:跳过提示和安全检查,包括写入.git、.claude等受保护路径。
在会话期间按 Shift+Tab,可在 default、acceptEdits 和 plan 之间循环切换。状态栏会显示当前模式,例如 ⏵⏵ auto mode on 或灰色的 ⏸ manual mode on。默认情况下,其他模式不会加入此循环。账号满足要求后,auto 会加入循环。只有在使用 --permission-mode bypassPermissions 或 --dangerously-skip-permissions 启动会话时,bypassPermissions 才会加入循环。dontAsk 永远不会出现在循环中,因此请使用 claude --permission-mode dontAsk 设置它。
Auto 模式还需要较新的模型;该模式完全不显示,通常就是因为缺少此条件。截至 August 2026,文档列出的受支持模型包括 Anthropic API 上的 Claude Opus 4.6 或更高版本、Sonnet 4.6 或更高版本,以及 Fable 5。文档还说明,Sonnet 4.5 等较旧模型在任何提供商上都不受支持。如果 Claude Code 报告 Auto 模式不可用,说明其中一项要求未满足。这不是临时服务中断,等待不会解决问题。
有两项控制在所有模式下都有效,包括 bypassPermissions:deny 规则和明确的 ask 规则。无论会话以哪种模式启动,这两项都是您始终保留的控制项。
自动模式分类器会阻止哪些操作
分类器是一个单独的模型。它会读取待执行的操作,并判断该操作是否符合您的要求。文档用一句话说明了它的职责:
单独的分类器模型会在操作运行前进行检查,阻止超出您请求范围的操作、面向无法识别基础设施的操作,以及看起来由 Claude 读取的恶意内容驱动的操作。
默认会阻止以下操作。这些是服务器运维人员最常遇到的类别:
- 下载并执行代码,例如
curl | bash - 在生产环境中部署和执行迁移
- 强制推送
- 修改共享基础设施
- 打开隧道或反向 shell,使本地服务可从公网访问
- 将实时凭据或令牌打印到会话记录或文件中
默认允许以下操作:
- 在工作目录中操作本地文件
- 安装锁定文件或清单中声明的依赖项
- 只读 HTTP 请求
- 推送到您当前操作的仓库中的任意分支
不要依据上面的摘要进行操作。运行 claude auto-mode defaults,以 JSON 格式输出完整的规则列表,并查看您所安装版本随附的规则集。
在依赖此功能前,需要注意两个已记录的限制。首先,分类器可以看到您的消息、工具调用和 CLAUDE.md 内容,但工具结果会被移除。因此,Claude 从文件或网页中读取的文本不能直接影响分类器。其次,如果分类器连续 3 次阻止某个操作,或在一次会话中累计阻止 20 次,自动模式会暂停,Claude Code 会恢复提示您确认。这些阈值无法配置。在带有 -p 标志的非交互模式下,没有人可以响应提示,因此重复触发阻止会直接中止会话。
第二种行为在远程服务器上尤其容易造成问题。无人值守运行一旦触发限制就会停止,并等待一个没有查看终端的人。解决方法的另一部分是缩小代理的任务范围;一项促使代理执行可行的最小变更的技能可避免会话逐渐扩展到分类器会阻止的大量操作。
settings.json 中模式的存放位置
上面的内容在设置文件中构成一个对象。
{
"permissions": {
"defaultMode": "auto",
"allow": [
"Bash(npm run test *)",
"Bash(git status)"
],
"ask": [
"Bash(git push *)",
"Bash(docker compose up *)"
],
"deny": [
"Read(./.env)",
"Read(./secrets/**)",
"Bash(curl *)"
]
}
}规则按以下顺序评估:deny,然后是 ask,最后是 allow。系统会按照此顺序使用第一个匹配项决定结果,后面更窄的规则不会覆盖前面更宽泛的规则。针对 Bash(aws *) 的 deny 规则会阻止 aws s3 ls,即使您同时允许了该确切命令。因此,deny 规则不能包含例外。
ask 是 auto 模式中最有用的规则类型。auto 模式会取消例行提示,而 ask 规则会针对您希望由人员确认的特定命令恢复提示。您的部署命令应放在这里。如果您希望代码离开服务器前经过确认,Bash(git push *) 也应放在这里。将凭据文件保存在 deny 中是另一项配套措施,并且应与首先防止代理访问凭据结合使用。
设置文件本身按优先级从低到高排列:
~/.claude/settings.json:您的用户设置,应用于每个项目。.claude/settings.json:项目设置,提交到代码仓库。.claude/settings.local.json:您针对单个代码仓库的个人设置,并由 git 忽略。- 由管理员部署的托管设置。在 Linux 上,该文件是
/etc/claude-code/managed-settings.json。任何内容都不能覆盖托管权限规则,包括命令行标志。
这里有一个有明确文档说明原因的陷阱。从 Claude Code v2.1.142 开始,如果 defaultMode: "auto" 来自 .claude/settings.json 或 .claude/settings.local.json,就会被忽略。这样可以防止代码仓库通过附带设置文件为自身授予 auto 模式。将它设置在该位置后,会话会以 default 模式启动,且不会在任何位置打印错误。请将该行移到 ~/.claude/settings.json。运行 /permissions,列出每条有效规则及其来源文件。
关闭模式的两个开关
管理员有两个紧急关闭开关,二者都接受字符串 "disable",而不是布尔值。
{
"permissions": {
"disableAutoMode": "disable",
"disableBypassPermissionsMode": "disable"
}
}文档明确说明了应将它们放在哪里:
要阻止使用bypassPermissions或auto模式,请在任意设置文件中将permissions.disableBypassPermissionsMode或permissions.disableAutoMode设置为"disable"。在无法被覆盖的托管设置中,这些选项最有用。
disableAutoMode 会从 Shift+Tab 周期中移除 auto,并在启动时拒绝 --permission-mode auto。disableBypassPermissionsMode 对旁路模式执行相同操作,并且可在任意作用域中生效。因此,您可以在自己的 ~/.claude/settings.json 中设置它,从而禁止自己在凌晨2点的生产服务器上进入不希望使用的模式。对于其他人也会使用的服务器,应改为将两项都放入 /etc/claude-code/managed-settings.json,因为用户设置文件归用户所有,而托管设置文件不属于用户。
为什么 VPS 上的自动模式需要隔离边界
分类器一次只检查一个操作。它不会限制已批准操作随后执行的内容。文档对此有明确说明:
分类器是按操作执行的控制机制,而不是隔离边界。因此,对于无人值守运行,隔离边界仍可提供纵深防御;而对于 --dangerously-skip-permissions,隔离边界则是必需的。
因此,在远程主机上,正确的组合是自动模式加上一个即使丢弃也可以接受的环境,而不是 bypassPermissions 加上侥幸心理。文档仅建议在隔离环境中使用绕过模式,例如无法访问互联网的容器、虚拟机或开发容器;在这些环境中,Claude Code 无法损坏宿主系统。运行数据库和反向代理的 VPS 不属于这些环境。
在服务器上,以下三点最重要。以普通用户运行 Claude Code,绝不要使用 root。为该用户提供一个工作目录,不要让它接触其他有读取价值的内容。与其修复主机,不如重新构建主机;这也是使用每项任务完成后都丢弃的一次性虚拟机的理由。上述措施背后的加固细节,从创建用户到配置防火墙规则,已在在 VPS 上运行 Claude Code 的完整安全检查中介绍,此处不再重复。
Claude Code 会自行强制执行 root 规则。在 Linux 和 macOS 上,如果以 sudo 身份或 root 身份运行,它会拒绝以绕过模式启动:
--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons在受识别的沙箱内,这项检查会被跳过。因此,对于自主运行容器任务,文档建议使用以非 root 用户运行 Claude Code 的开发容器。如果你通过 SSH 从手机或笔记本电脑驱动代理,同样的原则也适用于在 tmux 中保持运行的长期 Claude Code 会话:会话运行期间,没有人会查看提示内容。
在 Ubuntu VPS 上设置 Bash 沙箱
内置沙箱会限制 Claude 运行的每条 Bash 命令对文件系统和网络的访问,操作系统也会对其子进程强制执行相同限制。在 Linux 上需要安装两个软件包。
sudo apt-get install bubblewrap socat启动 Claude Code 并运行 /sandbox。面板会打开 Mode、Overrides 和 Dependencies 选项卡,其中 Dependencies 会列出缺少的软件包。依赖项检查在启动时执行,因此安装软件包后必须重启 Claude Code,否则面板仍会将这些软件包报告为缺失。
在 Ubuntu 24.04 及更高版本中,默认的 AppArmor 策略会阻止 bubblewrap 创建所需的用户命名空间,因此沙箱无法启动。检查当前服务器是否受此影响:
sysctl kernel.apparmor_restrict_unprivileged_userns如果显示 0,或出现表示该密钥不存在的错误,则无需执行任何操作。如果显示 1,则表示 bwrap 需要单独的配置文件:
sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>
profile bwrap /usr/bin/bwrap flags=(unconfined) {
userns,
include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor该配置文件仅作用于 bwrap 本身,不作用于它在沙箱中运行的命令。然后在设置中收紧边界:
{
"sandbox": {
"enabled": true,
"filesystem": {
"denyRead": ["~/"],
"allowRead": ["."]
},
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"]
}
}
}该代码块应放入项目的 .claude/settings.json,因为只有从项目设置中解析 . 时,它才会指向项目根目录。将相同的行放入 ~/.claude/settings.json 后,. 会改为解析到 ~/.claude,这样 denyRead 规则就会阻止访问项目文件,并且每条命令都无法读取需要编辑的代码。
请注意该沙箱未覆盖的范围。沙箱会限制 Bash 及其子进程。内置文件工具在 Claude Code 进程内部运行,而 MCP(模型上下文协议)服务器和钩子是独立进程,会在主机上不受限制地运行。若要将所有这些进程置于同一边界内,请将整个 Claude Code 进程运行在容器、虚拟机或 @anthropic-ai/sandbox-runtime 软件包中;截至本文撰写时,该软件包仍属于 beta 研究预览版。
每种环境应使用哪种模式?
个人笔记本上的单人仓库
使用 auto,并为需要人工确认的操作设置 ask 规则。您就在键盘前,分类器回退机制确实可以等待您的处理,而且影响范围被限制在您控制的一台机器内。14 August 的默认设置就是针对这种情况制定的。
共享 VPS
按用户使用 auto,并在每个用户自己的 ~/.claude/settings.json 中设置。运行 Claude Code 的账户不能是 root,也不能读取其他用户的工作目录。在 /etc/claude-code/managed-settings.json 中将 disableBypassPermissionsMode 部署为 "disable",同时配置保护共享路径的拒绝规则。共享主机最能说明 bypassPermissions 不适用,因为该模式假定存在的隔离边界并不存在:其他租户就在这个边界之内。
CI 和无人值守会话
使用 dontAsk,并明确列出任务所需的命令,即 allow。没有人会查看提示时,自动拒绝是正确的失败方式。自动模式同样以非交互方式运行,但分类器反复阻止操作会中止 -p 会话,因此任务在执行到一半、部分工作已经完成时失败。仅在根据镜像重建的容器或虚拟机中使用 bypassPermissions,不要在同时运行重要服务的主机上使用它。
FAQ
Claude Code 何时将自动模式设为默认模式?
从 2026 年 8 月 14 日起,Pro、Max 和 Team 计划的新会话将默认使用自动模式。文档还说明,您可以随时切换模式;您自行设置的默认模式会保持不变,除非您接受一次性切换提示;由组织管理的默认模式不会改变。公告指出,在首阶段推出期间,Enterprise 计划以及使用 API 的账户仍可选择不启用自动模式。请查看状态栏,确认会话实际处于哪种模式;自动模式下状态栏显示 ⏵⏵ auto mode on。
在 VPS 上,我应该使用自动模式还是 bypassPermissions?
使用自动模式,并配合隔离边界。分类器会在每项操作运行前进行检查,但文档明确说明,这只是针对单项操作的控制,不构成隔离边界。因此,无人值守运行仍应使用容器、虚拟机,或您愿意重建的服务器。bypassPermissions 会完全跳过检查,文档规定只能用于隔离环境。在 Linux 上以 root 身份运行时,Claude Code 不会以该模式启动,并会输出 --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons。
如何阻止服务器上的任何人使用自动模式或 bypass 模式?
在 /etc/claude-code/managed-settings.json 中,将 permissions.disableAutoMode 和 permissions.disableBypassPermissionsMode 设置为字符串 "disable"。托管设置的优先级高于其他所有作用域,因此任何用户设置文件和命令行标志都无法覆盖它们。disableAutoMode 会从 Shift+Tab 循环中移除 auto,并在启动时拒绝 --permission-mode auto。disableBypassPermissionsMode 在任何作用域中都有效,因此单个用户也可以在自己的 ~/.claude/settings.json 中设置它。
为什么我的 defaultMode: "auto" 设置被忽略?
因为设置位于错误的文件中。从 Claude Code v2.1.142 开始,如果 defaultMode: "auto" 来自 .claude/settings.json 或 .claude/settings.local.json,就会被忽略。这样可以防止仓库通过附带设置文件来为自身授予自动模式。会话将以 default 模式启动,且不会显示错误。将设置移到 ~/.claude/settings.json,然后运行 /permissions,确认每条生效规则来自哪个文件。如果自动模式仍不可用,请检查模型要求:Sonnet 4.5 等较旧模型不受任何提供商支持。