claude-permissions-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Permissions Audit

权限审计

Review and reorganize Claude Code permission settings so global settings are the source of truth, project-local files stay minimal, and read vs write operations have clear separation.

审查并重新组织Claude Code权限设置，使全局设置成为可信源，项目本地文件保持精简，且读写操作有明确区分。

When to Use

使用场景

Reviewing what tools and commands are pre-allowed
Cleaning up accumulated ad-hoc permission entries
After adding a new MCP server and deciding which operations to pre-allow
Ensuring global vs project-local settings are properly split
Periodic hygiene check on permission sprawl

审查哪些工具和命令已被预允许
清理累积的临时权限条目
添加新的MCP服务器后，决定预允许哪些操作
确保全局与项目本地设置合理拆分
定期检查权限扩散情况

Phase 1: Discover All Settings Files

阶段1：发现所有设置文件

Scan for every settings file that contributes to the effective permission set.

Locations to check:

```
~/.claude/settings.json
```
— global settings (source of truth)
```
<project>/.claude/settings.json
```
— project shared settings (committed)
```
<project>/.claude/settings.local.json
```
— project local settings (gitignored)
```
~/.claude/.claude/settings.local.json
```
— home directory project local
Any dotfiles-managed copy (e.g.
```
home/.claude/settings.json
```
in a dotfiles repo)

Read all of them in parallel. If a file doesn't exist, note it and move on.

扫描所有对有效权限集有贡献的设置文件。

需检查的位置：

```
~/.claude/settings.json
```
— 全局设置（可信源）
```
<project>/.claude/settings.json
```
— 项目共享设置（已提交）
```
<project>/.claude/settings.local.json
```
— 项目本地设置（已被Git忽略）
```
~/.claude/.claude/settings.local.json
```
— 主目录项目本地设置
任何由dotfiles管理的副本（例如dotfiles仓库中的
```
home/.claude/settings.json
```
）

并行读取所有文件。如果文件不存在，记录后继续。

Phase 2: Audit

阶段2：审计

For each permission entry across all files, assess:

Redundancy — Is this entry already covered by a broader rule elsewhere?
- Example:
```
Bash(gws calendar events:*)
```
  is redundant when
```
Bash(gws:*)
```
  exists globally
Misplacement — Is this general-purpose but stuck in a project-local file?
- Example:
```
Bash(python3:*)
```
  in project local when it's useful everywhere
Inconsistent granularity — Are similar tools allowed at different specificity levels?
- Example: Global has
```
gh pr list
```
  ,
```
gh pr view
```
  individually, but project local has
```
gh:*
```
Missing read/write distinction — Are read-only and write operations mixed together?
Stale entries — One-time approvals that accumulated (e.g., a specific git command with hardcoded paths)

Present findings as a table with issues and proposed resolution for each.

对所有文件中的每个权限条目进行评估：

冗余性 — 该条目是否已被其他地方的更宽泛规则覆盖？
- 示例：当全局存在
```
Bash(gws:*)
```
  时，
```
Bash(gws calendar events:*)
```
  属于冗余条目
错位 — 该条目是通用功能，但被放在项目本地文件中？
- 示例：
```
Bash(python3:*)
```
  在项目本地文件中，但它在所有场景都有用
粒度不一致 — 同类工具的允许级别是否不同？
- 示例：全局单独允许
```
gh pr list
```
  、
```
gh pr view
```
  ，但项目本地允许
```
gh:*
```
缺乏读写区分 — 只读和写入操作是否混合在一起？
过期条目 — 累积的一次性批准条目（例如带有硬编码路径的特定Git命令）

将调查结果以表格形式呈现，列出每个问题及建议解决方案。

Phase 3: Propose Reorganization

阶段3：提出重组方案

Design the new layout following these principles:

遵循以下原则设计新的配置布局：

Global settings (source of truth)

全局设置（可信源）

Organize permissions into labeled sections by grouping related entries together. Do NOT use JSON comments (// or /* */) — settings.json must be valid JSON. Instead, rely on the ordering of entries to convey grouping. Within the allow array, cluster related permissions together in this order:

Section order (group entries in this sequence, no separators needed):

filesystem reads            — cat, tree, grep, wc, file reads
<lang> inspection           — go doc, cargo check, linters (no side effects)
GitHub CLI reads            — gh pr list/view/diff, gh issue list (no mutations)
external tool reads         — calendar, slack CLI, other read CLIs
web reads                   — WebSearch, WebFetch with domain allowlist
MCP <service> reads         — list, get, describe, search operations
build / test / install      — go build, cargo test, pnpm install (local side effects)
skills                      — Skill(superpowers:*), etc.

将权限按相关条目分组，组织成带标签的部分。请勿使用JSON注释（//或/ /） — settings.json必须是有效的JSON。相反，依靠条目的顺序来传达分组。在allow数组中，按以下顺序将相关权限聚类在一起：

部分顺序（按此顺序分组条目，无需分隔符）：

filesystem reads            — cat, tree, grep, wc, 文件读取
<lang> inspection           — go doc, cargo check, 代码检查工具（无副作用）
GitHub CLI reads            — gh pr list/view/diff, gh issue list（无变更操作）
external tool reads         — 日历、Slack CLI、其他只读CLI
web reads                   — WebSearch、带域名白名单的WebFetch
MCP <service> reads         — list、get、describe、search操作
build / test / install      — go build, cargo test, pnpm install（本地副作用）
skills                      — Skill(superpowers:*), 等。

Project-local settings (minimal overrides)

项目本地设置（最小化覆盖）

Only keep entries that are genuinely project-specific:

Broader tool access needed for a specific workflow (e.g.,
```
Bash(gh:*)
```
for a repo that creates PRs frequently)
Project-specific MCP tools not used elsewhere
Temporary elevated access during active development

仅保留真正属于项目特定的条目：

特定工作流所需的更宽泛工具访问权限（例如，对于频繁创建PR的仓库，允许
```
Bash(gh:*)
```
）
其他项目不使用的项目特定MCP工具
活跃开发期间的临时提升权限

Clarifying questions

澄清问题

Before applying, ask the user about edge cases. Common questions:

Scope of CLI tools: Should
```
gh:*
```
(all subcommands) go global, or keep read-only globally with broader access per-project?
MCP write operations: Which write operations (send message, create issue) should stay prompted vs pre-allowed?
Environment separation: Should dev and prod data sources have the same read access, or should prod be more restrictive?
Dotfiles sync: Does the user maintain a dotfiles copy that needs updating?

Adapt questions to what's actually ambiguous — don't ask about things that are obvious from context.

在应用方案前，询问用户关于边缘情况的问题。常见问题：

CLI工具范围：
```
gh:*
```
（所有子命令）应设为全局允许，还是全局仅允许只读操作，每个项目单独设置更宽泛的权限？
MCP写入操作：哪些写入操作（发送消息、创建Issue）应保持需要确认，还是预允许？
环境分离：开发和生产数据源的只读权限是否应相同，还是生产环境应更严格？
Dotfiles同步：用户是否维护需要更新的dotfiles副本？

根据实际模糊点调整问题 — 不要询问上下文已明确的内容。

Phase 4: Apply Changes

阶段4：应用变更

Once the user confirms the plan:

Write the updated global settings file
Write the trimmed project-local settings file
Update any dotfiles copies to stay in sync
Clear out entries from other local files that were absorbed into global

一旦用户确认方案：

写入更新后的全局设置文件
写入精简后的项目本地设置文件
更新所有dotfiles副本以保持同步
清除其他本地文件中已被全局设置吸收的条目

Phase 5: Summary

阶段5：总结

Present a before/after comparison:

File	Before	After
Global	N flat entries	M entries in K sections
Project local	X entries	Y entries (project-specific only)

List what moved where, and what still requires prompting (write operations not pre-allowed).

呈现前后对比：

文件	变更前	变更后
全局	N个扁平条目	K个部分中的M个条目
项目本地	X个条目	Y个条目（仅项目特定）

列出哪些条目被移动到何处，以及哪些操作仍需确认（未预允许的写入操作）。