每次确认 Bash 正常吗

Claude Code 对 Bash 命令弹确认，先不要当成配置坏了。Bash 能跑脚本、改文件、联网、删除目录，也能间接触发工具链里的危险动作，所以默认要更谨慎。

真正需要排查的是：它是不是连 git status、git diff、pnpm run lint 这类你愿意长期放行的命令也一直问。如果是，就查 allow 规则、ask/deny 规则、权限模式和 settings 加载位置。

先看 /permissions 里有什么

进入 Claude Code 会话后先运行 /permissions。不要直接去改 settings。权限面板能看到当前 allow、ask、deny 规则，以及这些规则来自哪个 settings 文件。

如果同一个命令一直弹确认，通常是 allow 没匹配上、ask 先命中、deny 挡住了，或者当前会话根本没加载你修改的 settings。

/permissions

允许后还会问先查哪里

Claude Code 保存的是权限规则，不是“我以后相信所有 Bash”。如果下次命令字符串、工作目录、复合命令结构或启动参数变了，它仍然可能继续问。

最常见的情况是你上次允许了 npm test，这次 Claude Code 想跑 cd packages/api && npm test、timeout 30 npm test、npm test -- --watch=false，规则没有覆盖到当前实际命令。

• 命令多了参数，精确匹配规则不再命中。
• 命令前面加了 cd、timeout、npx、docker exec 或其它 wrapper。
• 复合命令里有多个子命令，每个子命令都需要单独匹配。
• 当前项目目录变了，之前保存的规则不在这个目录下生效。
• 命令被 ask 或 deny 规则先命中。

把安全命令写进 allow

先只放行你能接受自动执行的本地检查。不要为了少弹窗直接放行全部 Bash。下面这组适合放在用户 settings 或项目共享 settings 里，具体命令按项目包管理器改。

这段配置只处理 Claude Code 的 Bash 权限，不会替你判断命令是否应该运行。项目规则里仍然要写清楚什么时候可以跑 lint、typecheck 或测试。

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(pnpm run lint)",
      "Bash(pnpm run typecheck)"
    ]
  }
}

临时启动时怎么放行

如果只想本次会话少问几条命令，用 --allowedTools。它适合一次性排查，不适合替代团队共享配置。

命令行参数优先级高于项目和用户 settings。排查时如果发现 settings 写对但行为不对，检查启动命令里有没有临时参数覆盖。

claude --allowedTools "Bash(git status)" "Bash(git diff *)" "Bash(pnpm run lint)"

通配符应该怎么写

Bash 规则支持 * 通配符。Bash(npm run *) 会匹配以 npm run 开头的命令，Bash(* --version) 会匹配以 --version 结尾的命令。

通配符不是安全边界。Bash(git *) 能匹配很多 Git 命令，其中也可能包括你不想自动放行的动作。能写精确命令，就不要写过宽前缀。

复合命令还会问怎么办

Claude Code 会识别 &&、||、;、管道和换行这类 shell 分隔符。一个 allow 规则不会因为匹配了前半段，就自动放行后半段。

如果 Claude Code 想跑 git status && pnpm run lint，你需要分别允许 git status 和 pnpm run lint。这不是重复配置，而是避免一个安全前缀带出另一个高风险命令。

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(pnpm run lint)"
    ]
  }
}

只读命令还会问先查什么

Claude Code 内置识别一批只读 Bash 命令，例如 ls、cat、grep、wc、diff 和只读形式的 git。这些命令通常不需要确认。

但只读命令加上可能写入或执行的参数、未加引号的 glob、find -exec、find -delete，或者和其它命令组合后，仍然可能触发确认。不要只看命令名字，要看完整命令。

ask 和 deny 应该怎么分

减少弹窗不等于全部放进 allow。更稳的做法是：安全检查进 allow，状态改变进 ask，高破坏动作进 deny。

deny 优先级最高。只要 deny 命中，就算 allow 里也写了类似规则，Claude Code 也不会执行。

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(pnpm run lint)"
    ],
    "ask": [
      "Bash(pnpm install *)",
      "Bash(git commit *)",
      "Bash(git push *)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

权限模式要不要改

如果你只是想让几条 Bash 检查少弹窗，优先改 allow 规则，不要先切全局权限模式。权限模式改变的是整个会话的默认行为。

acceptEdits 会减少文件编辑确认，但其它 Bash 命令仍可能继续问。plan 适合先让 Claude Code 分析。dontAsk 适合预先定义好 allow 的非交互环境。bypassPermissions 只适合隔离环境或一次性强控制场景。

沙箱打开后哪些弹窗会减少

Claude Code 的权限和沙箱不是同一层。权限决定 Claude Code 能不能尝试使用 Bash、Read、Edit、WebFetch 等工具；沙箱限制 Bash 子进程能碰到的文件系统和网络边界。

在支持沙箱的环境里，如果启用了 autoAllowBashIfSandboxed，沙箱内 Bash 命令可能不会再逐条弹确认。这个行为不是 allow 规则失效，而是沙箱边界替代了部分命令确认。显式 deny 仍然应该保留。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true
  }
}

公司策略拦住了怎么办

如果 /permissions 或 /status 显示 managed settings，先不要继续改用户 settings。组织策略优先级更高，用户配置和项目配置不能覆盖。

这种情况下你只能在被允许的范围内补项目规则，或者让管理员确认哪些 Bash 命令可以进入 allow。不要用本地绕过方式处理公司账号的权限策略。

• 看到 managed settings：先确认组织允许的权限模式和工具范围。
• 看到 allow 写了但仍然问：检查 ask / deny / managed rule 是否先命中。
• 看到命令被直接拒绝：不要继续改 prompt，先确认是不是企业策略限制。

怎么验证不再反复弹窗

改完权限后，不要马上交给 Claude Code 跑大任务。先让它执行一组你明确允许的安全命令，并要求它不要安装依赖、不要提交、不要联网。

成功标准是：允许的检查命令能直接跑；安装依赖、提交推送、网络下载仍会停下来；敏感文件仍然不能读。

请做一个权限验证任务：
1. 运行 git status
2. 运行 git diff
3. 运行 pnpm run lint
4. 不安装依赖，不提交代码，不访问网络
5. 如果需要其它 Bash 命令，先说明原因并等待确认
6. 最后报告哪些命令没有弹窗，哪些命令仍需要确认

参考来源

相关文章