Claude Code 权限配置，允许自己做个甩手掌柜

老实说，刚用 Claude Code 那会儿，我感觉自己不像个开发者，倒像个坐在流水线尽头的质检员。

那天晚上，我正准备让它帮我重构一个老旧的模块。我敲下指令，它开始飞速运转，读文件、分析逻辑、生成新代码……就在我准备喝口咖啡欣赏它的杰作时，屏幕突然卡住，弹出一个冷冰冰的确认框：“是否允许写入文件？”

我按下回车。它继续写，写了三行，又停了：“是否允许执行 npm run test？”

我看了一下它修改的内容又按回车，在接下来的一个小时，它的每一次询问我都在注意，但是只有20%的修改是真的需要确认。

那一刻我突然意识到，问题不在 AI，而在我没有给它画好安全的边界。出于安全考虑，Claude Code 默认对几乎所有操作都采取“谨慎询问”策略，但这显然不适合日常开发。。

摸清权限的五层优先级

我开始研究它的配置层级。原来，Claude Code 的权限系统有着严密的五层优先级体系（从高到低）：

1. Managed（企业托管策略）：/etc/claude-code/managed-settings.json
2. CLI 命令行参数：当前会话临时覆盖
3. Local（本地个人配置）：.claude/settings.local.json（自动 gitignore）
4. Project（项目共享配置）：.claude/settings.json（提交至 Git）
5. User（用户全局配置）：~/.claude/settings.json

在这个体系中，拒绝（deny）规则拥有绝对的最高优先级，一旦某项操作被拉黑，任何低层级的配置都无法覆盖。这个设计是个亮点。

核心配置文件分享

弄懂了规则，开始动手写那自己的 .claude/settings.json。策略是：读操作全放行，源码编辑按路径放行，构建与写操作分级管理，破坏性操作坚决拒绝。

以下是目前在用的叫欸配置模板，过滤一些根据项目细化的配置：

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Bash(git status)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(python3:*)",
      "Bash(mkdir -p:*)"
    ],
    "ask": [
      "Edit(src/**)",
      "Write(src/**)",
      "Bash(git commit:*)",
      "Bash(git push:*)",
      "Bash(npm install:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo:*)",
      "Bash(curl:* | bash)",
      "Edit(.env.production)",
      "Write(/Users/yourname/.ssh/**)"
    ]
  }
}

判断原则

实际中还是需要根据项目细化一些配置， 决定一条规则是放 allow 还是 ask，最核心的判断原则是：这个操作如果 AI 执行出错，修复成本有多高？

claude code — 2026 / 01/18