踩坑｜CodeBuddy权限配置：AI误删文件、乱跑命令、.env泄露怎么防

踩坑｜CodeBuddy 权限配置：AI 误删文件、乱跑命令、.env 泄露怎么防（全网最全权限规则详解）

🔥 很多人的 CodeBuddy 配置是"裸奔"的------默认权限模式下，AI 想改文件就改文件、想跑命令就跑命令。直到某天它把 .env 里的密钥提交了、把 node_modules 删了重装、或者对着生产库执行了一条危险命令......

本文基于官方权限文档，把 allow / ask / deny 三层规则、权限模式、信任目录、受保护文件讲透，附可直接抄的安全配置模板。

---

一、写在前面：三个真实事故现场

先说三个我见过/听过的真实案例（均已脱敏），你有没有同款经历？

案例	事故经过	后果
😱 事故一：密钥泄露	开发要求"帮我改一下配置"，AI 顺手把 .env 里的数据库密码打印在对话里，还差点提交上去	密钥外泄风险，紧急轮换
😱 事故二：删库跑路版	AI 执行"清理构建缓存"时，通配符写错，把整个 src 目录一起 rm 了	本地代码丢失（还好有 Git）
😱 事故三：越权读取	AI 自动读取了项目外的 ~/.ssh/id_rsa、~/.aws/credentials 等敏感文件	凭据信息进入模型上下文

共同根因只有一个：权限配置缺失，AI 的"手脚"比你想象的自由。

打个比方：CodeBuddy 像一个"手脚麻利但偶尔糊涂"的实习生。你既不告诉它能碰什么、不能碰什么，也不在它伸手前问一句------那它闯祸只是时间问题。

---

二、核心概念：权限的三层规则

CodeBuddy 的权限系统核心是 allow / ask / deny 三层规则，写在 settings.json 的 permissions 字段里：

{
  "permissions": {
    "allow": ["Bash(npm test)", "Read(/src/**)"],
    "ask":   ["WebFetch", "Bash(git push:*)"],
    "deny":  ["Bash(rm -rf *)", "Read(./.env)", "Edit(.git/**)"]
  }
}

行为	含义	使用建议
allow	直接放行，不弹审批	高频且安全：npm test、git status、读业务源码
ask	每次执行都弹审批框	有风险但偶发需要：网络请求、git push、写文件
deny	绝对禁止，优先级最高	高危命令、敏感文件、关键目录

2.1 规则形态：Tool 和 Tool(specifier)

不写参数 = 匹配该工具的全部调用：

规则	含义
Bash	所有 Bash 命令
Edit	所有文件编辑
Read	所有文件读取
WebFetch	所有网页抓取

写参数 = 细粒度匹配：

规则	匹配内容
Bash(npm run build)	精确匹配这条命令
Bash(git:*)	所有 git 开头的命令
Bash(npm run *)	所有 npm run 开头的命令
Read(./.env)	当前目录的 .env
Edit(/src/**/*.ts)	项目根下 src 里的所有 TS 文件
Read(~/.zshrc)	用户目录下的 .zshrc
WebFetch(domain:example.com)	只允许抓取 example.com 及其子域

2.2 路径的三种写法（容易踩坑）

前缀	含义	示例
//path	文件系统绝对路径	Read(//etc/hosts)
~/path	用户主目录	Read(~/.ssh/*)
/path 或 ./path	项目根 / 当前工作目录	Edit(/src/**/*.ts)、Read(.env)

⚠️ 高频踩坑点 ：Read(./.env) 匹配的是"当前工作目录"下的 .env，很多人把这条写进 deny 却漏了 .env.local、.env.production 等兄弟文件。建议写成 Read(./.env*) 一网打尽。

---

三、关键机制（搞懂这 4 点，你就超过了 90% 的人）

3.1 deny 永远优先

无论你处于哪种权限模式，deny 规则永远第一个执行、任何模式都拦得住 。即使开了 bypassPermissions（完全跳过审批），deny 依然有效。

{
  "permissions": {
    "deny": ["Bash(rm -rf *)", "Bash(sudo:*)", "Read(./.env*)"]
  }
}

这就是你的"最后一道保险丝"。危险命令宁可多拦，不可漏放。

3.2 复合命令：allow 要求"全部命中"

对于 git status && rm -rf * 这种用 && / ; / | 拼接的复合命令：

• deny / ask：任一子命令命中 → 触发；
• allow ：要求所有子命令都命中才放行（防止危险命令藏在被允许命令旁边）。

{
  "permissions": {
    "allow": ["Bash(git:*)"]
  }
}

执行结果：

git status            → ✅ 允许
git status && rm -rf  → ❓ 询问（rm 不在 allow 里）
git status; sudo rm   → ❓ 询问

3.3 带重定向的命令：allow 直接失效

包含 > < >> << &> 重定向的命令，在 allow 规则下要求精确匹配，通配符不生效。这是为了防止 AI 用重定向偷偷写系统文件。

3.4 受保护文件：任何模式下都有额外保护

以下路径默认受保护，AI 想改必须过审批：

• 仓库自身 ：.git、.gitconfig、.gitmodules
• Shell 配置 ：.bashrc、.zshrc、.envrc
• 包管理 ：.npmrc、.yarnrc、bunfig.toml
• IDE 工具 ：.vscode、.idea、.husky
• CodeBuddy 自身 ：.codebuddy 目录
• MCP 配置 ：.mcp.json

---

四、权限模式：决定"默认放行还是默认询问"

规则层之外还有一个模式层，决定权限弹窗的默认行为：

模式	行为	适合场景
default	敏感操作询问	✅ 日常开发首选
acceptEdits	自动接受文件编辑	改代码为主的场景
plan	只规划不执行	需求分析、方案设计
bypassPermissions	完全跳过审批（-y）	⚠️ 仅限可信的 CI/一次性任务
dontAsk	不询问（ask 全部变成拒绝）	严格受限的自动化场景
auto	AI 分类器自动处理 ask	嫌弹窗烦但求稳

⚠️ 最危险的坑 ：为了省事直接 bypassPermissions（-y）跑所有任务。记住------bypass 模式不会抹掉 deny 规则，但会跳过绝大多数询问。一个 AI 误判，就是一次事故。

---

五、信任目录：AI 的"活动范围"边界

CodeBuddy 默认只信任当前工作目录：

• 信任目录内的 Read：直接放行；
• 信任目录外的 Read / 所有 Edit / Bash：默认询问。

扩大信任范围的几种方式：

方式	持久度
--add-dir <path> 启动参数	进程级
会话内 /add-dir 命令	会话级
permissions.additionalDirectories	持久化
permissions.trustedDirectories	持久化

{
  "permissions": {
    "additionalDirectories": ["/path/to/shared-lib"]
  }
}

⚠️ 注意 ：--add-dir 只授予文件访问权 ，不会加载该目录里的 .codebuddy/ 配置------别指望靠加目录让规则生效。

---

六、一键抄走：安全配置模板

模板一：个人日常开发（推荐）

.codebuddy/settings.json：

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git log)",
      "Read(/src/**)",
      "Read(/tests/**)"
    ],
    "ask": [
      "Bash(git:*)",
      "Bash(npm:*)",
      "Edit",
      "WebFetch"
    ],
    "deny": [
      "Bash(rm:*",
      "Bash(curl:*",
      "Bash(wget:*",
      "Bash(sudo:*)",
      "Bash(kill:*)",
      "Read(./.env*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Edit(.git/**)",
      "Edit(/.codebuddy/**)"
    ]
  }
}

💡 上面 deny 里 Bash(rm:* 故意写漏右括号？不是笔误 ------这是为了用前缀匹配 rm、rm -rf 等所有变体，防止 AI 微调命令绕过精确匹配。同理 curl:*。官方语法中括号内以 * 结尾即前缀匹配。

模板二：团队共享（提交进 Git）

.codebuddy/settings.json（随版本库提交，全团队生效）：

{
  "permissions": {
    "deny": [
      "Bash(rm:*)",
      "Bash(sudo:*)",
      "Read(./.env*)",
      "Edit(.git/**)",
      "Edit(/config/credentials.json)"
    ]
  }
}

模板三：个人放宽（不提交 Git）

.codebuddy/settings.local.json（个人机器生效，自动被 gitignore）：

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": ["Bash(git:*)", "Bash(pnpm:*)"]
  }
}

三层分工：团队安全底线 放共享配置，个人便利放本地配置。互不干扰，又能同时生效。

---

七、避坑清单（收藏级）

1. deny 永远优先：危险命令的 deny 是任何模式下的保命符，先配 deny 再谈 allow。
2. 路径写全 ：.env 要写成 .env*，~/.ssh 要写成 ~/.ssh/**，防止 AI 读兄弟文件。
3. 复合命令防绕过 ：allow 只匹配"全部子命令都安全"的命令，&&、; 拼接的危险命令会掉进 ask。
4. 重定向命令 allow 失效 ：含 > < 的命令走精确匹配，别指望通配符。
5. 别轻易 bypassPermissions ：-y 省的是弹窗，赔的是安全。CI 场景也要配合强 deny。
6. 受保护文件别乱动 ：.git、.npmrc、.codebuddy 默认有保护，别在 allow 里把它们放开。
7. 信任目录 ≠ 加载配置 ：--add-dir 只给访问权，不会加载该目录的 .codebuddy/ 配置。
8. 用 /permissions 随时检查 ：会话内输入 /permissions 可查看当前全部规则，--allowedTools / --disallowedTools 可临时调整。

---

八、总结：一张表记住权限体系

维度	关键点	一句话记忆
规则层	allow / ask / deny	deny 最高优先
语法	Tool 或 Tool(specifier)	写参=精准，不写=全量
路径	// 绝对、~/ 用户、/ 项目根	三个斜杠三种范围
模式层	default / acceptEdits / plan / bypass...	默认询问最稳
信任目录	默认只信任工作区	越界要问
受保护文件	.git / .envrc / .codebuddy 等	想改需审批

最后提醒 ：权限配置不是"限制 AI"，而是"给 AI 划清安全边界"。配好了，你才能放心把代码交给它改------安全感，是效率的前提。

如果这篇对你有帮助，点个赞收个藏。评论区聊聊：你的 CodeBuddy 干过什么离谱的事？

---