Lesson 2 · 7 min

settings.json Configuration

Where the harness reads permissions, hooks, env, and model.

~/.claude/settings.json (user) and .claude/settings.json (project) configure permissions (allow/deny patterns), hooks (event-driven shell commands), env vars, and default model. Always commit the project settings so the team shares the same harness behavior.

Production scenario

Real-world example: Team-wide safety baseline

A platform team commits a project-scoped .claude/settings.json to every repo:

{
  "permissions": {
    "deny": [
      "git push --force*",
      "rm -rf*",
      "kubectl delete*",
      "npm publish*"
    ],
    "allow": ["npm install", "npm test", "git diff*"]
  },
  "hooks": {
    "PreToolUse": [".claude/hooks/check-no-secrets.sh"]
  }
}

Every engineer's Claude Code session inherits these guardrails the moment they cd into the repo. New hires are productive without anyone having to remember to set this up.

Why this matters: the *project* settings file is how a team encodes shared safety policy. Commit it, version it, treat it like any other source-controlled config.

Knowledge points in this lesson

Project settings: .claude/settings.json
User settings: ~/.claude/settings.json
Settings carry permissions, hooks, env, model
Commit project settings to share with team
Allow/deny lists control tool access
Env vars in settings flow to subprocesses

Quick check

Claude CodeSelect one

Which Claude Code event fires before a tool is executed?