settings.json Generator

What settings.json actually controls

Claude Code reads a settings.json file to decide what it is allowed to do, which model to run, what environment it runs in, and a handful of behavior flags. There are three places it can live, and they layer on top of each other: enterprise managed policy at the system level, then ~/.claude/settings.json for your personal defaults, then .claude/settings.json committed in the project for the whole team, and finally .claude/settings.local.json for machine-specific overrides you never commit. More specific files win over broader ones, so a project rule beats your personal default, and your local file beats the shared project file.

The generator above assembles the most common keys - permissions, model, env, cleanupPeriodDays, includeCoAuthoredBy, and a statusLine command - and emits valid JSON you can paste straight in. It only writes the keys you actually set, so you get a lean file instead of a wall of defaults you did not choose.

The permissions block is the important part

Permissions are how you tell Claude Code what it can do without asking every time, what it must ask about, and what it must never do. Each rule is written as Tool(pattern) - for example Read(**) to allow reading any file, Bash(npm run test:*) to allow that command family, or Edit(src/**) to scope edits to a folder. The deny list is your safety net: put Read(./.env) and your secrets folders there so the model can never open them, even if you later loosen the allow list.

• allow - actions that run without a prompt. Keep this specific. Read(**) is usually fine; Bash(*) is not.
• ask - actions that always pause for your confirmation. Good for anything that touches the network or your git remote, like Bash(git push:*).
• deny - a hard block that overrides allow. This is where secrets, credentials, and destructive commands go.
• defaultMode - what happens to anything not matched by a rule: default prompts you, acceptEdits auto-accepts edits, plan is read-only, and bypassPermissions skips prompts entirely.

Environment variables and behavior flags

The env block sets environment variables for every Claude Code session in that scope. Teams use it to pin things like a shared base URL, a proxy, or feature flags so nobody has to remember to export them. Behavior flags round out the file: includeCoAuthoredBy controls whether Claude adds a co-author trailer to commits it makes, and cleanupPeriodDays controls how long local chat transcripts are retained before they are pruned.

Project settings versus personal settings

Commit .claude/settings.json when you want the whole team to inherit the same permissions and model. Keep personal preferences - your editor status line, your own env quirks - in ~/.claude/settings.json or in .claude/settings.local.json, which should be gitignored. A good rule of thumb: if a teammate cloning the repo would benefit from the setting, it goes in the shared project file; if it is about your machine, it stays local.

How to use the output safely

1. Create a .claude folder in your project root if it does not exist.
2. Paste the generated JSON into .claude/settings.json.
3. Confirm your deny list actually names your real secret paths, not just the example .env.
4. Restart Claude Code so it re-reads the file, then run a low-stakes prompt to confirm the permission prompts behave the way you expect.
5. Add .claude/settings.local.json to your .gitignore so personal overrides never get committed.

Common mistakes to avoid

• Allowing Bash(*) - this hands the model an unrestricted shell. Scope command families instead.
• Forgetting to deny your real secrets - the example rules protect ./.env, but your keys may live elsewhere.
• Committing settings.local.json - it is meant to be personal and often contains machine-specific paths.
• Setting bypassPermissions on a shared team file - that removes the confirmation prompts for everyone.