在使用 Claude Code 时，开发者常担心 AI 会过度修改文件。通过合理配置权限模式，可以在保持工作效率的同时确保代码安全。本文将指导你如何设置默认模式、配置规则顺序，并验证配置是否生效。
选择合适的默认权限模式
在 Claude Code 的 /permissions 界面中，系统会列出当前规则和来源文件。defaultMode 决定了会话打开时进入的权限模式。官方文档提供了以下选项：
default和manual：两者是同一个起点，都会在每类工具第一次使用时请求确认。acceptEdits：自动接受文件编辑和常见文件系统命令，适合已清楚工作区边界、想减少重复确认的场景。plan：更保守的模式，只做读取和只读命令，不主动修改源码。bypassPermissions：跳过大部分提示，但仅适用于隔离环境，不建议作为日常默认值。
如果你的目标是降低风险，优先使用 manual 模式。只有在确认 Claude Code 只会在工作区内进行常规编辑时，才考虑切换到 acceptEdits。对于新用户，建议第一天停留在 manual 模式，观察它会访问哪些文件，再决定下一步操作。
配置规则顺序与危险路径拦截
权限规则的顺序至关重要：deny 优先于 ask，ask 优先于 allow。这意味着你可以先锁定最敏感的路径，再让少量可信命令通过。常见做法包括：
- 将
Read(./.env)、Read(./.env.*)、Read(./secrets/**)等规则加入deny。 - 如果不希望会话拉取未知安装脚本，可将
Bash(curl *)一并拦截。
在团队仓库中，建议将共享限制写入 .claude/settings.json，确保所有协作者使用同一套规则。如果只想为自己添加保护，可写入 .claude/settings.local.json。不同 scope 会共同参与权限判断，因此你可以将团队级 deny 放在项目中，再在本机配置少量 allow，无需为单个项目重写整套设置。
如果同一条规则在不同 scope 中重复出现，建议保留项目中的硬约束，让本机配置仅负责少量放行。这样既能守住仓库边界，又不会将个人习惯绑定到团队仓库中。
对于高风险目录（如数据库备份、密钥文件、发布脚本、临时下载目录），最实用的方法是先将它们加入 deny，然后仅对白名单中的少数命令放行。这能显著降低误触发概率，并在排查问题时更容易定位是读权限、写权限还是命令本身的问题。
验证配置与排查常见问题
Claude Code 会在大多数设置变化后自动重载，包括 permissions。但改完后不要仅凭感觉判断，应直接运行 /status 命令，查看 Setting sources 是否已读取你刚编写的配置文件。这一步能立即暴露两类问题：JSON 写错位置，或被更高优先级的 managed settings 覆盖。
在团队仓库中操作时，建议将通用限制写成可提交的项目配置，个人试验则放在本机 local 配置中。这样团队能复用你的安全边界，你也能随时回退，避免因临时调试打乱仓库默认策略。
需注意：manual 只是 default 的别名，表示默认按需确认，并非“完全没有弹窗”。如果看到弹窗就急于关闭权限，可能会放过真正该关注的风险。更稳妥的做法是先保留弹窗，再用规则将其数量压到最少。
新安装后的推荐操作顺序为：先用 manual 观察权限请求，再补充 deny 规则保护密钥和敏感目录，最后仅在需要批量修改文件时切换到 acceptEdits。记住两个关键命令：先看 /permissions 了解规则来源，再看 /status 确认当前会话使用的配置。
