点了「Yes, and don't ask again」之后，规则写在哪？

在 Claude Code 里点一次「以后别再问」，不等于这条规则会按你以为的方式留下来。批准会不会写入文件、写到哪一份、会不会进仓库，取决于工具类型，以及你用的是 CLI 还是 VS Code 扩展。下面依据官方 settings / permissions 文档整理，不是一次泄漏事件的复现。

第一步：先分清这次批准会不会落盘

官方权限说明里，不同类型的批准去向不同：

• Bash 命令、WebFetch 域名：选择「Yes, and don't ask again」后，规则会永久写入项目里的 .claude/settings.local.json，对这个仓库的后续会话都有效。
• 文件修改（Edit/Write）：批准只在当次会话有效，不会写入上述文件。
• 有些提示只提供一次性批准，没有「以后别再问」。这时要么批准这一次，要么自己在 /permissions 里加规则。

所以「我点过了，为什么下次还要问」不一定是故障：可能那次本来就不会落盘，也可能后来被更高优先级的 ask 或 deny 规则挡住了。

第二步：确认写到哪一份文件

在 git 仓库里，CLI 会把这条 allow 规则写到仓库根目录的 .claude/settings.local.json。从子目录启动也是写根目录；在 worktree 里，则写到主工作区根目录。CLI 只写这份本地文件。

VS Code 扩展的批准卡片可以让你选择目标文件，包括会提交给同事的项目共享 .claude/settings.json。选错就会变成仓库里的团队规则，而不只是你自己的本地覆盖。

需要核对来源时，在会话里打开 /permissions：它会列出每条规则，以及对应的 settings 文件。

第三步：确认文件会不会被提交

Claude Code 自己第一次写入 .claude/settings.local.json 时，通常会把 **/.claude/settings.local.json 加入全局 git excludes，避免提交。如果你是手建这份文件，而它还没被 Claude Code 写过，就要自己把它加进 .gitignore。

如果这个文件已经被 git 跟踪，它会按仓库文件处理：allow 规则也要先通过工作区信任，并且可能被提交、被克隆。批准会把命令写成 allow 规则，命令里若夹着密码或 token，也会一起留下。批准前先看完整命令，不要把密钥写进会被永久记住的命令。

第四步：还在反复询问时，先查规则优先级

本地 allow 并不能压过项目或组织里的 ask 规则。规则判定顺序是：先 deny，再 ask，再 allow。匹配到 ask，即使另有更具体的 allow，也仍会询问。

改完后可用 /status 看 Setting sources 是否包含 Project local settings，再用 /permissions 确认规则落在哪份文件。不要只靠「我记得点过」。

披露： 我维护 QuickRouter。本文依据 Claude Code 官方文档整理批准落点与核查步骤，不是对某次公开仓库泄漏的复现或取证。一切以你当前客户端与官方文档为准。

来源

• Settings files and precedence
• Configure permissions