设置 Settings

设置 Settings

一个团队里：CTO 说「全公司禁用 force push」、技术负责人说「这个项目用 pnpm」、你说「我本地用 opus 模型」。这三条规矩，作用范围不同、制定人不同、优先级不同。

settings.json 就是管这些的。它是一套有层级的配置体系，让企业、项目、个人各管各的，互不打架。

四层配置体系

settings.json 按作用范围分四层，从全局到局部：

层级	文件位置	作用域	谁来维护
企业级	managed-settings.json（系统级路径）	全公司	IT / 安全团队
用户级	~/.claude/settings.json	当前用户所有项目	你自己
项目级	.claude/settings.json	当前项目（随仓库走）	团队共享
本地级	.claude/settings.local.json	当前项目、当前机器	你本地私有

讲个小故事说清四层的用处：

• 企业级写「禁止 force push、必须走内部网关」——全公司通用，员工改不了，最高优先级。
• 用户级写「我偏好 opus 模型、状态栏显示 git 分支」——你的个人习惯，跨项目生效。
• 项目级写「本项目用 pnpm、连着 GitHub MCP」——团队共享，提交进 git。
• 本地级写「我本地 Postgres 的连接串」——只你这台机器有，不提交进 git。

优先级：高覆盖低

四层配置会合并，遇到冲突时，优先级高的覆盖低的。顺序是：

企业级  >  用户级  >  项目级  >  本地级

也就是说：企业级定的规矩，谁都不能改；用户级的偏好，覆盖项目级的默认；本地级是优先级最低的，只在前三层没提到时才生效。

这个设计很关键——它让不同角色各司其职：企业管安全红线、个人管习惯偏好、团队管项目规范、本地管私有配置。互不干扰，冲突时按优先级裁决。

permissions：放行、拒绝、询问

settings.json 里最重要的字段是 permissions。它控制 Claude 能干哪些操作、不能干哪些。三个子字段：

字段	作用
allow	自动放行这些操作，不问
deny	直接拒绝这些操作，Claude 碰都不让碰
ask	每次都询问你，你同意才执行

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

读这个配置：

• 跑 npm test、git status、读 src 下的文件——自动放行，不打扰你。
• git push --force、rm -rf——直接拒绝，Claude 想都别想。
• git push（普通推送）——每次问你，你确认才推。

这个三档设计让你精细控制风险：安全的放开（省心）、危险的封死（安全）、重要的留个确认（稳妥）。

注意：MCP 工具的权限不支持通配符，必须逐个写明。详见 MCP。

env：环境变量

env 字段注入环境变量给 Claude 调用的命令。最常见的是放 API token：

{
  "env": {
    "GITHUB_TOKEN": "ghp_xxxxx",
    "ANTHROPIC_API_KEY": "sk-ant-xxxxx"
  }
}

这样 Claude 跑的命令、连的 MCP 都能用这些环境变量，而不用把密钥写死在代码或 MCP 配置里。

注意：本地级 settings.local.json 是放密钥的好地方——它通常被 .gitignore 排除，不会进 git。

sandbox：沙箱配置

sandbox 字段配置沙箱执行环境。让 Claude 的命令在受限环境里跑——限制它能访问的文件、网络，即使命令有问题也跑不出沙箱。

{
  "sandbox": {
    "enabled": true,
    "network": "deny"
  }
}

这适合不信任的代码、探索陌生仓库、跑 AI 生成的脚本时——给 Claude 一个「沙盒」让它玩，弄不脏你的系统。企业部署时，sandbox 是安全的重要一环。详见企业部署板块的 沙箱与 Devcontainer。

enabledPlugins：插件开关

控制装了的插件哪些启用、哪些禁用。详见 Plugins：

{
  "enabledPlugins": {
    "code-review-workflow": true,
    "legacy-refactor": false
  }
}

其它常用字段

settings.json 还有一些字段值得知道：

字段	作用
hooks	配置 Hooks，9 大事件钩子
statusLine	配置 Status Line 自定义状态栏
model	默认用哪个模型
extraKnownMarketplaces	注册额外插件市场源

可以看到，settings.json 是个总装配文件——Hooks、Status Line、Plugins、模型、权限、环境变量，全在这里管。

/config 和 /permissions：可视化管理

不想手写 JSON？Claude Code 提供交互式管理：

• /config：打开设置界面，可视化改各项配置。
• /permissions：专门管权限，增删 allow/deny/ask 规则。

这两个命令会读你的 settings.json，让你在界面里改，改完写回文件。比手敲 JSON 友好得多。

一个完整示例

一个项目级 settings.json，集成了权限、钩子、状态栏、插件：

{
  "model": "sonnet",
  "permissions": {
    "allow": ["Bash(pnpm:*)", "Bash(git status)"],
    "deny": ["Bash(git push --force:*)"],
    "ask": ["Bash(git push:*)"]
  },
  "env": {
    "GITHUB_TOKEN": "${GITHUB_TOKEN}"
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "pnpm lint && pnpm test" }
        ]
      }
    ]
  },
  "statusLine": {
    "type": "command",
    "command": "echo \"model: $CLAUDE_MODEL | branch: $(git branch --show-current)\""
  },
  "enabledPlugins": {
    "code-review-workflow": true
  }
}

这一份配置就定义了：用 sonnet、放行 pnpm、禁 force push、推送要问、自动跑 lint+test、状态栏显示模型和分支、开了代码审查插件。一份文件，整个项目规矩全齐。

一句话总结

settings.json 是规章制度——四层层级（企业→用户→项目→本地）高覆盖低，permissions 三档（allow/deny/ask）控风险，env 注入变量，sandbox 限沙箱，enabledPlugins 管插件。一份文件，整个项目规矩全齐。

---

最后一站，去 状态栏 Status Line 给你的终端配一个「仪表盘」。🚀