1. 六种权限模式到底差在哪：从 default 到 bypassPermissions 的完整对照
Claude Code 是 Anthropic 推出的命令行 / IDE 编程助手，它能读文件、改代码、跑命令，但每做一步要不要问你，取决于一个叫「权限模式」的东西。你可以把它理解成给助手配的门禁卡：default 是访客卡，进每个房间都要登记；acceptEdits 是员工卡，办公区随便走，机房还得刷卡；bypassPermissions 则是万能钥匙，哪都能进，包括不该进的地方。搞不清这六种模式，团队里就会出现「有人被弹窗烦死、有人被误删文件吓死」的两极分化。
这篇面向需要在团队中统一权限策略的开发者，把 default、acceptEdits、plan、auto、dontAsk、bypassPermissions 六种模式的作用、开启方式、适用场景整理成一张能直接抄的表，并给出可复制的 settings.json 配置片段，最后演示怎么通过切换 defaultMode 亲眼看到各模式的拦截与放行行为。核心检索词就是 Claude Code 权限模式、defaultMode、bypassPermissions、settings.json 这几个，你搜到这篇基本就能一次配明白。
先说清楚一个容易混淆的点：权限模式不是「安全等级」，而是「确认策略」。它决定的是 Claude Code 在执行某类操作前，是直接做、弹窗问你、还是直接拒绝。同一个模式在不同项目里风险完全不同——在一个只有文档的仓库里跑 bypassPermissions 可能没事，在一个连着生产配置的仓库里跑就是灾难。所以选模式的第一原则不是「哪个爽」，而是「这个目录里最坏能坏到什么程度」。
六种模式里，default、acceptEdits、plan、auto、dontAsk、bypassPermissions 的激进程度大致是递增的，但 dontAsk 是个特例：它不弹窗，却也不放行，而是「静默拒绝」——只有你提前在配置里批准过的工具和命令才能跑，其余一律拒绝。这跟 bypassPermissions 的「全放行」正好是两个极端。理解这一点，后面配 CI 流水线时就不会选错。
还有一个高频误区：很多人以为 Shift+Tab 能切到所有模式。实际上 Shift+Tab 只在 default、acceptEdits、plan、auto 这几个之间循环，dontAsk 和 bypassPermissions 不在这个循环里，必须通过命令行参数或 settings.json 开启。这个设计是有意的——把最危险和最受限的两种模式藏起来，避免手滑切进去。
下面这张表是全文的骨架，建议先扫一遍，再往下看配置细节。
| 模式 | 核心作用 | 开启方式 | 适用场景 |
|---|---|---|---|
| default | 只读操作直接执行，改文件 / 跑命令弹窗询问 | 默认启动；claude --permission-mode default；"defaultMode": "default" | 新项目、敏感代码、首次使用 |
| acceptEdits | 自动接受文件编辑和常见文件系统命令，高风险命令仍询问 | Shift+Tab；claude --permission-mode acceptEdits；"defaultMode": "acceptEdits" | 日常编码、文件重构 |
| plan | 只读，仅分析、读文件、写方案，不改任何东西 | Shift+Tab；claude --permission-mode plan；消息前加/plan | 大重构前梳理方案、风险评估 |
| auto | 自动执行大多数操作，内置安全检查，高风险回退到手动确认 | claude --permission-mode auto；"defaultMode": "auto"；部分场景 Shift+Tab | 自动化脚本、长任务 |
| dontAsk | 静默拒绝，只有配置里批准过的才能执行 | claude --permission-mode dontAsk；"defaultMode": "dontAsk" | CI/CD、受限自动化环境 |
| bypassPermissions | 跳过几乎所有权限检查，仅保护 .git/.claude 等关键目录 | claude --permission-mode bypassPermissions或--dangerously-skip-permissions；"defaultMode": "bypassPermissions" | 仅限隔离容器 / 虚拟机 |
表格里最需要盯住的是最后一行。bypassPermissions 的官方参数名直接叫--dangerously-skip-permissions，dangerously 这个词不是装饰。它意味着 rm -rf、改系统文件、推送敏感代码这些操作都可能无确认执行。我试过在一次性容器里用它跑批量重构，确实快，但绝对不要在本地开发目录直接开。
理解了这张表，接下来就是怎么把它落到 settings.json 里，以及怎么验证配置真的生效了——很多人配完以为生效了，其实被会话级参数覆盖了，这个坑后面会专门讲。
2. 接入前的准备：拿到 Key 并确认 settings.json 路径
在动权限模式之前，得先让 Claude Code 能正常跑起来。这一步涉及 API Key 和 Base URL 的配置，如果你用的是 TaoToken 这类兼容 Anthropic 接口的服务，配置方式和官方基本一致，只是把地址和 Key 换成自己的。官网入口在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api ，注意 API 地址不带 UTM 参数，配置时别把查询串抄进去。
先说 Key 从哪来。登录后进控制台，在 API Keys 页面创建一个新 Key，复制出来。这个 Key 只在创建时完整显示一次，丢了就得重建。创建入口在 https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite ，建议创建时按项目命名，比如claude-code-team-a，方便后面轮换和排查。
拿到 Key 之后，要确认 Claude Code 读的是哪个配置文件。这里有个关键点：Claude Code 的配置分好几层，优先级从高到低大致是「命令行参数 > 项目级 .claude/settings.json > 用户级 ~/.claude/settings.json」。团队统一权限策略时，通常把 defaultMode 放在项目级配置里，这样每个成员拉下代码就自动生效；个人偏好放用户级。路径写错是新手最常见的翻车点，下面把两个路径都列清楚。
用户级配置路径（macOS / Linux）：
~/.claude/settings.json项目级配置路径（在仓库根目录）：
<你的项目根目录>/.claude/settings.jsonWindows 下用户级路径通常是C:\Users\<用户名>\.claude\settings.json。如果你不确定当前生效的是哪个文件，可以在项目里跑claude后用/config之类的命令查看，或者直接看启动时有没有报配置解析错误。
环境变量这块也要提一句。Claude Code 支持通过环境变量注入 API Key 和 Base URL，常见的是ANTHROPIC_API_KEY和ANTHROPIC_BASE_URL。如果你在 CI 里跑，用环境变量比写进文件更安全，因为文件可能被提交进仓库。下面是一个典型的 shell 配置：
export ANTHROPIC_API_KEY="你的Key" export ANTHROPIC_BASE_URL="https://taotoken.net/api"注意 Base URL 结尾不要多加/v1之类的路径，具体以接入文档为准。文档入口在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，配置前扫一眼能省很多 404 排查时间。
准备工作做完，你应该具备三个东西：一个可用的 Key、确认好的 settings.json 路径、以及知道 Base URL 该填什么。这三样齐了，下一节的配置片段才能直接复制粘贴生效。如果这一步就卡住，先别急着调权限模式，权限模式是「配好之后怎么管」，连不上是另一个问题。
顺便说下模型 ID 的确认。不同服务商支持的模型名不一样，配置里如果写了不存在的模型，请求会直接报错。你可以在模型对话页面先手动发一条消息验证 Key 和模型是否匹配，入口在 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 。确认能正常对话后，再回到 settings.json 配权限模式，排查链路会清晰很多。
3. 可复制的 settings.json 配置：六种 defaultMode 写法
这一节是全文最实用的部分，直接给可复制的 JSON 片段。Claude Code 的 settings.json 里，权限模式由defaultMode字段控制，取值就是那六个字符串。下面按模式逐个给最小可用配置，你可以整段替换，也可以只改defaultMode的值。
最安全的起步配置，适合新项目或敏感仓库：
{ "defaultMode": "default" }日常开发最常用的配置，自动接受文件编辑，减少确认疲劳：
{ "defaultMode": "acceptEdits" }只想让助手出方案、不碰代码时用：
{ "defaultMode": "plan" }自动化脚本场景，内置安全检查兜底：
{ "defaultMode": "auto" }CI/CD 白名单场景，只有批准过的工具能跑：
{ "defaultMode": "dontAsk" }隔离容器里才用的激进配置：
{ "defaultMode": "bypassPermissions" }实际项目里，settings.json 往往不止 defaultMode 一个字段，还会配 permissions 白名单、环境变量等。下面给一个更完整的团队级配置示例，把 defaultMode 和权限白名单放在一起，这样即使切到 dontAsk，预先批准的命令也能正常跑：
{ "defaultMode": "acceptEdits", "permissions": { "allow": [ "Bash(npm run lint)", "Bash(npm run test:*)", "Bash(git status)", "Bash(git diff:*)" ], "deny": [ "Bash(rm -rf:*)", "Bash(git push:*)" ] } }这段配置的读法是：默认走 acceptEdits，文件编辑自动过；allow里的命令即使在高限制模式下也放行；deny里的命令无论什么模式都拒绝。团队统一策略时，把deny里塞上rm -rf、git push、curl外发这类高危操作，能挡掉大部分手滑。
如果你用的是 Cline MCP 或 Codex 这类工具，配置思路类似，但字段名可能不同。以 Codex 的 auth.json 为例，它管的是认证信息，权限策略通常在另一个配置文件里。这里要强调「三件套」的概念：不管哪个工具，接入时都要确认 Base URL、Key、Model ID 三样齐全，缺一个就连不上或跑错模型。Claude Code 里 Base URL 和 Key 走环境变量或 settings，Model ID 在会话里选或配置指定。
CC Switch 这类多配置切换工具也常和 Claude Code 搭配用，它的作用是帮你在多套 Base URL / Key 之间快速切换，比如公司账号和个人账号分开。用 CC Switch 时同样要保证三件套完整，切换后建议跑一次验证请求，确认切过去的是预期配置。
配置写完保存，重启 Claude Code 让配置生效。这里有个细节：项目级配置改动后，如果会话已经开着，可能需要退出重进才会重新读取。别改完文件就在旧会话里测，那样测出来的是旧配置，容易误判。
最后提醒一句，settings.json 是 JSON 格式，不能有注释、不能有尾逗号。很多人从别处抄配置时带了//注释，结果解析失败，Claude Code 启动就报错。如果你不确定格式对不对，找个 JSON 校验工具过一遍再保存。
4. 验证各模式实际行为：切换 defaultMode 看拦截与放行
配完不验证等于没配。这一节给一套可跟做的验证流程，通过切换 defaultMode，亲眼看到每种模式对同一操作的拦截与放行差异。验证的核心思路是：准备一个「改文件」和一个「跑命令」的动作，在不同模式下观察 Claude Code 是直接做、弹窗问、还是拒绝。
先准备一个干净的测试目录，避免误伤真实项目：
mkdir -p ~/claude-perm-test && cd ~/claude-perm-test echo "hello" > demo.txt git init然后在这个目录里启动 Claude Code，让它做两件事：把 demo.txt 里的 hello 改成 world，以及跑一条git status。下面按模式逐个走。
验证 default 模式。把项目级配置设成{"defaultMode": "default"}，重启后启动 Claude Code，让它改 demo.txt。预期行为是弹窗询问你是否允许编辑，你拒绝它就不改，你同意它才改。跑git status这类只读命令则直接执行，不弹窗。这一步验证的是「只读放行、写操作询问」。
验证 acceptEdits 模式。改成{"defaultMode": "acceptEdits"}，重启，再让它改 demo.txt。预期是直接改，不弹窗。但如果你让它跑rm demo.txt这类删除命令，仍然会询问。这一步验证的是「编辑自动过、高危命令仍拦」。
验证 plan 模式。改成{"defaultMode": "plan"}，重启，让它改 demo.txt。预期是它只输出方案，比如「我建议把 hello 改成 world，执行这条命令即可」，但不会真的动文件。你去看 demo.txt，内容还是 hello。这一步验证的是「完全只读」。
验证 auto 模式。改成{"defaultMode": "auto"}，重启，让它改 demo.txt 并跑git status。预期是低风险操作直接过，如果你让它跑git push或删除操作，会回退到手动确认。这一步验证的是「自动为主、高危兜底」。
验证 dontAsk 模式。改成{"defaultMode": "dontAsk"}，并在 permissions.allow 里只放Bash(git status)。重启后让它跑git status，预期直接执行；让它改 demo.txt，预期静默拒绝，不弹窗也不改。这一步验证的是「白名单内放行、其余全拒」。
验证 bypassPermissions 模式。这一步强烈建议只在一次性容器或虚拟机里做。改成{"defaultMode": "bypassPermissions"}，重启，让它改文件、跑命令，预期几乎全部直接执行，不弹窗。你可以在容器里故意让它跑一条删除命令，观察它是否真的无确认执行——看到结果你就明白为什么官方叫它 dangerously。
验证过程中有个常见现象：改了 settings.json 但行为没变。八成是会话没重启，或者命令行参数覆盖了配置。比如你启动时带了claude --permission-mode plan，那不管 settings.json 写什么，都以命令行为准。排查时先确认启动命令有没有带权限参数。
另一个验证技巧是用/plan前缀。在任意模式下，单条消息前加/plan，这条消息会以 plan 模式处理，只出方案不改文件。这适合在 acceptEdits 模式下临时做一次「只看不动」的分析，不用切全局模式。
跑完这六轮，你对每种模式的实际手感就有了。团队推广时，可以把这套验证流程写成 onboarding 文档，新成员照着跑一遍，比口头讲十遍都管用。
5. 常见报错排查：401、local proxy failed、reading choices、OAuth
权限模式配好之后，实际用起来还会撞上一些报错。这些报错大多跟权限模式无关，而是接入层的问题，但容易被误判成「模式没生效」。下面按真实报错逐个拆。
401 Unauthorized。这是最常见的，意思是 Key 无效或没带上。排查顺序：先确认环境变量ANTHROPIC_API_KEY有没有导出成功，用echo $ANTHROPIC_API_KEY看是不是空；再确认 Key 有没有过期或被删；最后确认 Base URL 有没有写错。如果你在 settings.json 里配了 Key，注意别把 Key 提交进仓库。401 跟权限模式完全无关，别去改 defaultMode。
local proxy failed。这个报错通常出现在你配了本地代理地址但代理没起来，或者 Base URL 指向了一个不可达的地址。排查时先确认ANTHROPIC_BASE_URL填的是https://taotoken.net/api这种可达地址，而不是http://localhost:xxxx这种本地地址（除非你确实在跑本地代理）。再确认网络能通，用curl -I https://taotoken.net/api看有没有响应。这个错也跟权限模式无关。
reading choices 相关报错。这类报错一般出现在响应解析阶段，常见原因是返回体格式和客户端预期不一致，或者模型 ID 写错了导致返回了错误结构。排查时先确认 Model ID 是服务商支持的，去模型对话页面手动发一条消息验证。如果手动对话正常，但 Claude Code 里报错，检查是不是配置里指定了一个不存在的模型名。三件套里的 Model ID 这一环最容易漏。
OAuth 相关报错。如果你用的是需要 OAuth 登录的方式，报错通常跟 token 过期或回调地址不匹配有关。这类问题优先看官方文档的认证章节，别在权限模式上浪费时间。OAuth 和 API Key 是两套认证体系，别混用。
除了这些，还有一个「假报错」：配置里 defaultMode 写了个不存在的值，比如"defaultMode": "accept"（少了 Edits），Claude Code 可能不报错但行为异常，回退到默认。排查时把六个合法值背下来：default、acceptEdits、plan、auto、dontAsk、bypassPermissions，大小写敏感，别写错。
再给一个排查通用套路：遇到任何报错，先跑一次最小验证请求，确认接入层是通的。最小验证就是手动发一条「你好」看有没有回复。通了，再怀疑权限模式；不通，先修接入。这个顺序能省掉大量瞎调配置的时间。
如果你在团队里推广，建议把这几类报错和对应排查步骤写进内部 wiki，新成员撞上直接查，不用每次来问。报错信息里如果出现permission字样，才往权限模式方向查；出现auth、401、proxy、choices、OAuth，都先查接入层。
6. 团队统一权限策略的落地建议与后续入口
把六种模式摸清之后，团队落地时还有几个实操建议。第一，项目级 settings.json 进版本控制，用户级配置不进。这样团队共享的是权限策略，个人偏好各自保留。第二，deny列表要写死高危命令，不管默认模式是什么，rm -rf、git push --force、外发 curl 这类都拒绝。第三，新成员 onboarding 时跑一遍第 4 节的验证流程，建立手感。
模式选择上，给一个团队默认建议：日常开发仓库用 acceptEdits，敏感仓库用 default，CI 用 dontAsk 配白名单，隔离容器才考虑 bypassPermissions。plan 模式适合在提大改动前让助手先出方案，auto 适合跑长任务但你又不想全程盯。
如果你还在选长期编码方案，或者团队要跑 Agent 类长任务，可以看下 Coding Plan，入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。接入和排障相关的文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，Key 管理在 https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 。想先手动验证模型行为，去模型对话页面 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 发几条消息最快。
最后留一个我踩过的坑：有次在项目级配置里把 defaultMode 设成 bypassPermissions 想图快，结果某次让助手「清理临时文件」，它把还没提交的改动一起删了。从那以后，任何非隔离环境我都至少用 acceptEdits，并且 deny 列表里加上删除类命令。权限模式是效率工具，但效率的前提是别把不该删的东西删了。
