你有没有这种体验：

Claude Code 在执行任务期间，遇到要写入文件时，弹窗让你确认。需要执行命令时，弹窗让你确认。你不管的话任务就直接卡在那，一直等待你确认。本来你期待的是能高度自动化完成的任务，却因为这权限申请让你不得不耗费不少精力去关注任务的执行情况。

用下来感觉不是在跟 AI 协作，而是在跟弹窗博弈。

这篇文章就是来解决这个问题的。我会把 Claude Code 的权限体系从头捋一遍，告诉你每个配置项是什么意思，什么情况用哪个，以及怎么在「给 AI Claude Code 最大权限」的同时，把真正危险的操作还是拦下来。

另外还有一个 Claude Code VSCode 插件用户必看的坑，踩了才知道有多隐蔽。

为什么 Claude Code 要有这套权限系统

这块先说人话。

Claude Code 不是个文本编辑器，它是个能直接操作你文件系统、执行 Shell 命令、推代码上 GitHub 的 AI Agent。

把这件事想清楚，你就会明白为什么它默认那么谨慎：AI 写错了你可以撤回，AI 执行了一条 rm -rf就没得撤了。

所以它的权限系统本质上是一条防线——哪些操作可以直接做，哪些需要你确认，哪些完全不允许。

理解了这个出发点，再看配置就不会觉得繁琐了。

六个 mode，你只需要记三个

Claude Code 的 defaultMode有六个值，但说真话，日常用到的就三个。我把它们从"最保守"到"最激进"排一下：

default（默认，最保守）

每次工具调用都问你。读文件问，写文件问，跑命令问。

适合第一次用，还没搞清楚 Claude 会干什么的阶段。或者你在操作特别重要的项目，宁可多点几下确认。

acceptEdits（文件党的选择）

文件读写类操作——Read、Edit、Write——自动通过，不问你。

但 Shell 命令（Bash）还是会弹窗。

说白了就是：改代码随便改，但执行命令还是要我点头。

这个平衡点对大多数开发场景是够的。你最怕的不是 Claude 改错了文件（那个你可以 git reset），你怕的是它执行了什么奇怪的命令然后你不知道。

bypassPermissions（全开，搭配 ask 用才安全）

所有操作，包括 Bash 命令，全部直接执行，不问你。

看起来很危险，但后面我会告诉你怎么搭配 ask规则，让它既不烦、又不失控。

剩下三个（auto、dontAsk、plan）属于进阶场景，一般用不到，这里不展开。

配置写在哪、怎么写

Claude Code 的项目级配置在 .claude/settings.json，用户全局配置在 ~/.claude/settings.json。

项目配置优先级更高，而且会跟着项目走（可以提交到 git），适合团队共享。

最基础的结构长这样：

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [],
    "deny": [],
    "ask": []
  }
}

allow— 显式放行某些操作，即使 defaultMode 比较保守，这里列出的也自动通过。

deny— 显式拒绝某些操作，Claude 无法执行，也不会问你。

ask— 强制弹窗确认，哪怕 defaultMode 设成 bypass 也还是会问。这个是后面的关键。

三种典型场景的推荐配置

场景 A：日常开发，想减少干扰但保留安全感

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

就这么简单。文件操作不打扰你，命令执行还是会问。

场景 B：有固定的脚本/命令想白名单化

比如你知道 Claude 经常要跑 npm run build，不想每次都点确认：

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": ["Bash(npm run *)"]
  }
}

allow里支持通配符，npm run *就是放行所有 npm run 开头的命令。

场景 C：某些路径绝对不让动

比如你有个 secrets/目录，里面放了密钥文件，绝对不能让 Claude 碰：

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(secrets/**)", "Edit(secrets/**)"]
  }
}

VSCode 插件用户必看：这里有个隐藏坑

如果你用的是 VSCode 插件版本，settings.json里配的 defaultMode可能根本没生效。

原因是插件有自己的一套权限控制，通过 VSCode 的设置项管理，默认值是 "default"，会把你 settings.json里的配置盖掉。

找到 VSCode 的 settings.json（通常在 ~/Library/Application Support/Code/User/settings.json），加上这一行：

{
  "claudeCode.initialPermissionMode": "acceptEdits"
}

这才是插件真正读的那个配置。

更隐蔽的坑：.claude/目录整体会弹窗

设好了 acceptEdits，你可能还是发现一件事：凡是 .claude/目录下的文件，改动都会弹窗——不管是 .claude/memory/、.claude/me/，还是其他子目录。

这是 Claude Code 的硬编码保护，意思是"AI 改自己的配置文件，我要盯一眼"。

你的第一反应可能是：在 allow里加上这些路径不就好了？

"allow": ["Edit(**/.claude/memory/**)", "Edit(**/.claude/me/**)"]

试过了。在 VSCode 插件里，这条规则对 .claude/目录无效——插件那层拦截在 allow规则之前，绕不过去。

真正的解法：bypass + ask 组合拳

.claude/目录的弹窗没法用 allow消掉，那就换个思路：

把 defaultMode 开到 bypassPermissions，然后用 ask把真正危险的操作单独拉回来弹窗。

ask规则有个特性：任何 mode 下都强制弹窗，包括 bypass，而且 VSCode 插件的配置也覆盖不掉它。

配置长这样：

{
  "permissions": {
    "defaultMode": "bypassPermissions",
    "ask": [
      "Bash(rm *)",
      "Bash(rm -rf *)",
      "Bash(git push*)",
      "Bash(git reset --hard*)",
      "Bash(git rebase*)",
      "Bash(sudo *)"
    ]
  }
}

VSCode 这边也要加两行：

{
  "claudeCode.initialPermissionMode": "bypassPermissions",
  "claudeCode.allowDangerouslySkipPermissions": true
}

效果：

你获得了流畅感，同时不可逆操作还是有人盯着。

一张决策图，收藏备用

你在用 Claude Code 做什么？
│
├── 刚开始用，不确定它会干什么
│   └── defaultMode: "default"（全部问你）
│
├── 日常开发，主要是改代码，不怎么用 .claude/ 目录
│   └── defaultMode: "acceptEdits"（文件操作免确认）
│       ├── 有些命令也不想确认？→ allow: ["Bash(你的命令 *)"]
│       └── 有些路径绝对不能动？→ deny: ["Edit(敏感目录/**)"]
│
└── 需要 Claude 自由读写 .claude/ 目录（配置、记忆文件等）
    └── defaultMode: "bypassPermissions"
        + ask: 列出 rm / git push / sudo 等危险命令
        + VSCode 插件额外加两行配置
        ⚠️ ask 规则兜底，不会完全失控

最后说一句

权限配置这块坑最多的地方不是配置项本身，是你以为配好了但其实没生效。

CLI 和 VSCode 插件读的是不同的配置入口，settings.json的 defaultMode和插件的 initialPermissionMode是两回事，两个都得设才算数。

合适的姿势是：先搞清楚自己用的是哪个版本，再对号入座配置。别一套配置通吃，容易踩坑。

就这样，配置搞定了，开始愉快地 Vibe Coding 吧。