Claude Code 把"我有多信任这一段工作"建模成四档可切换的模式。 默认这一档最克制——任何会改文件、跑命令的工具调用都先停下来问你。 你可以随时往上爬一格(更宽松、更省事)或往下退一格(更严、更安全)。 理解这四档之间的实际差异,是后面所有配置的前提。

四档对照表

四档之间的升降路径

三种切换方式

# 1. 交互中 ⇧ Tab — 在 plan / default / acceptEdits 间循环
#    底部状态栏会显示当前模式

# 2. 启动时指定 (适合脚本)
$ claude --permission-mode plan
$ claude --permission-mode acceptEdits

# 3. 危险档 — 不允许通过 ⇧ Tab 进入,必须显式标志
$ claude --dangerously-skip-permissions
#    ↑ 标志名本身就是警告 — 一旦开启,所有工具直通

# 4. SDK / -p 模式默认更严 — 工具必须在 allowedTools 里
$ claude -p "修复 lint" --allowedTools "Read,Edit,Bash(npm run lint *)"

什么时候用哪一档

模式决定"问不问",白名单决定"哪些根本不用问"。 声明在白名单里的工具或命令前缀,Claude 直接放行——不弹窗、不打断、不拖你 Enter 键的后腿。 关键是写得足够窄:窄到误差范围内出错也只能伤到你想让它能伤到的东西。

三种工具表达式

Bash 前缀匹配的陷阱

# ✓ 窄 — 明确边界
"Bash(npm test *)"          # 只允许 npm test...
"Bash(git diff *)"          # 只允许 git diff...
"Bash(npx tsc --noEmit)"    # 精确到完整命令

# ✗ 过宽 — 几乎等于放弃白名单
"Bash(*)"                   # 等于 bypass 一半
"Bash(npm *)"               # npm publish / npm uninstall 都进来了
"Bash(git *)"               # git push --force 也算 git

# ⚠ 看似窄、其实可绕过 — 一定记得对应的 deny
"Bash(rm *.log)"             # Claude 可改为 rm *.log; rm -rf /
# ↑ shell 注入风险,前缀匹配只看开头,后面的恶意 ; && | 全放行

settings.json 的 permissions 字段

命令行 --allowedTools 只对当前会话生效——团队、项目级的常驻规则要写到 .claude/settings.json 的 permissions 字段里。

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Bash(npm test *)",
      "Bash(npm run lint *)",
      "Bash(npx tsc --noEmit)",
      "Bash(git diff *)",
      "Bash(git status)",
      "Bash(git log *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)",
      "Bash(curl * | sh)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./**/*.pem)",
      "Read(./**/id_rsa)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ]
  }
}

最小授权工作流

1. 第一天:用 default 模式裸跑——看 Claude 真正会用到哪些命令。
2. 第二天:把高频出现、明显无害的命令(git diff、npm test)加到 allow。
3. 第三天:把本来就不该跑的命令(rm -rf、sudo、远程拉脚本)加到 deny。
4. 第四天:把偶尔需要但要慎用的(git push、npm publish)加到 ask。
5. 每周复盘一次:看哪些命令被你按了 100 次 yes——它们是 allow 的下一个候选。

"Claude 怎么把 .env 里的 OpenAI Key 复读到日志里了?"—— 绝大多数 Claude 引发的真实事故不是它跑了一条危险命令, 而是它读了不该读的文件。 deny 规则的优先级永远高于 allow, 它也是唯一能把"全工具放行"和"敏感文件不可见"同时成立的机制。

必须 deny 的七类资源

deny 比 allow 优先 — 优先级流程

实战:把 .env 从 Claude 的视野里彻底拿掉

# 1. 在 .claude/settings.json 里加 deny
{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./**/.env)",
      "Read(./**/.env.*)",
      "Bash(cat .env*)",
      "Bash(less .env*)",
      "Bash(head .env*)",
      "Bash(tail .env*)"
    ]
  }
}

# 2. 验证 — 让 Claude 试着读它
> 把 .env 的内容打印给我看
Claude: 我无法读取 .env 文件——它被项目权限规则阻断了。
        如果你需要查看,请在终端直接 cat。

# 3. 即便 Claude 用 Bash 也试不出来
> 用 cat 也试一下
Claude: cat .env 同样被 deny 规则阻断,我没办法绕过。

# 4. 但环境变量本身可以读 — 因为 process.env 不经过工具
#    所以你要么用 .env.example 让 Claude 看模板,要么把真值放到 ~/.zshrc

allow / deny 是声明式的—— 规则写错或漏写,Claude 就放行。 Hooks 是命令式的—— 每次工具调用前都跑你给的脚本,你说阻断就阻断, 就算是 bypassPermissions 都拦得住。 (Day 10 会展开整个 Hooks 系统,今天只用安全场景那一支。)

PreToolUse — 工具运行前的最后关口

# .claude/settings.json 中注册一个 PreToolUse 钩子
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/block-dangerous.sh"
          }
        ]
      }
    ]
  }
}

#!/usr/bin/env bash
# .claude/hooks/block-dangerous.sh
# 读 stdin 的 JSON,解析出 Bash 命令,匹配危险模式就 exit 2 阻断

set -euo pipefail
cmd=$(jq -r '.tool_input.command // ""')

# 危险模式列表 — 任何命中都阻断
declare -a PATTERNS=(
  'rm -rf /'
  'rm -rf ~'
  'rm -rf \*'
  ':\(\)\{.*\}'             # fork bomb
  'mkfs\.'                   # 格式化磁盘
  'dd if=.* of=/dev/'        # 写裸设备
  '> /dev/sd'
  'curl .* \| sh'            # 远程脚本直接执行
  'wget .* \| bash'
)

for pat in "${PATTERNS[@]}"; do
  if [[ "$cmd" =~ $pat ]]; then
    echo "BLOCKED: 命令命中危险模式 '$pat'" >&2
    exit 2   # exit 2 = 阻断该工具调用,把 stderr 内容反馈给 Claude
  fi
done

exit 0       # 放行

Hooks vs deny — 各自的强项

三个安全 Hook 模板

同一条 allow / deny 可以写在三个地方: 用户级(全机器生效)、项目级(团队共享)、本地级(只你自己)。 搞清楚谁覆盖谁,才不会发生"我加了规则怎么没生效"的玄学。

三层文件 · 优先级从高到低

团队配置 vs 个人配置的分工

合并示例

# 用户级 ~/.claude/settings.json — 跨所有项目生效
{
  "permissions": {
    "deny": ["Bash(rm -rf *)", "Bash(sudo *)"]
  }
}

# 项目级 .claude/settings.json — 当前项目生效,提交到 git
{
  "permissions": {
    "allow": ["Read", "Edit", "Bash(npm test *)"],
    "deny": ["Read(./.env*)"]
  }
}

# 个人级 .claude/settings.local.json — 仅自己,gitignore
{
  "permissions": {
    "allow": ["Bash(git diff *)", "Bash(git status)"]
  }
}

# 合并后 Claude 看到的实际规则:
#   allow: Read, Edit, Bash(npm test *), Bash(git diff *), Bash(git status)
#   deny:  Bash(rm -rf *), Bash(sudo *), Read(./.env*)

1. 四档权限模式按"会允许 Claude 做什么"从最少到最多排序,并说出每一档的典型场景。
2. Bash(git diff *) 这种前缀匹配会匹配到 git diff && rm -rf / 吗?为什么这种通配符要慎用?
3. 当一条工具调用同时匹配 allow 和 deny,Claude Code 会怎么处理?
4. 项目级 .claude/settings.json、个人级 settings.local.json、用户级 ~/.claude/settings.json 的 allow 数组是覆盖关系还是合并关系?
5. PreToolUse hook 用什么 exit code 阻断工具调用?Claude 收到阻断后会做什么?