A shared settings.json makes Claude Code permissions safe by default for teams

A guide published on dev.to tackles a scaling problem that hits teams adopting Claude Code: permissions that work as personal habit for a solo developer lead to inconsistent, unreviewable agent behavior across a group. The proposed fix is a shared permissions file committed to the repository, so every developer's session starts from the same rules.

The guide — written by the makers of a workspace-setup tool it promotes at the end — describes the problem plainly: solo developers settle into their own approval patterns, teammates cannot see what anyone else's agent is allowed to run, and new hires click through prompts on day one without knowing which ones matter.

Which file does what

According to the guide, three of Claude Code's settings locations matter for teams. The repository-level .claude/settings.json applies to everyone working in the repo and is the file to commit. The .claude/settings.local.json file holds one developer's personal exceptions for that repository and stays out of git — Claude Code excludes it automatically when it creates the file itself, but a hand-created copy needs a .gitignore entry. The user-level ~/.claude/settings.json applies to one developer across all projects and never enters the repo. Organizations that need rules nobody can override can additionally use managed settings, which sit above all three.

Allow, ask, deny

The recommended shared file is deliberately short: an allow list for commands developers run constantly and that cannot do damage — lint, tests, type checks, read-only git; an ask list for actions that are fine but deserve a human glance, such as pushing, publishing or running a local migration; and a deny list for reads of secrets and any command the team never wants an agent to run.

Lists from different files are combined rather than replaced, the guide explains: a developer's personal allow rules add to the team's list, but they cannot remove the team's deny rules.

Deny rules win

Claude Code evaluates deny rules first, then ask, then allow, and the first match in that order decides; rule specificity does not reorder the check. The consequence, per the guide, is that an allow rule cannot carve an exception out of a deny rule: if the team file denies Bash(aws *), a developer adding Bash(aws s3 ls) to a local allow list is still blocked. That precedence is what makes the shared file dependable, since team deny rules hold no matter what anyone adds locally.

How rules match commands

Several details decide whether a rule does what its author intended:

• * matches any text in its position, so Bash(npm run test *) covers that command with any arguments.
• The space before a trailing * matters: Bash(ls *) matches ls and ls -la but not lsof, while Bash(ls*) matches lsof too.
• Compound commands are split into parts. Allowing Bash(npm run test *) does not approve npm run test && rm -rf build; each part must be allowed on its own, and a deny rule applies if any part matches it.
• File rules use paths: Read(./.env) covers one file, while Read(./secrets/**) covers everything under a folder.

Where permission rules stop

The guide is explicit that permission rules shape agent behavior but are not a security boundary on their own. A Bash rule matches the command text the agent writes, so the same program invoked through a variable, a script or sh -c may not match; the guide cites Claude Code's own documentation warning that rules restricting command arguments, such as limiting curl to one domain, are fragile. For real guarantees it recommends layering: sandboxing for filesystem and network limits that do not depend on how a command is written; PreToolUse hooks that run a custom check before every command and can block it, stored in the same shared settings file so the whole team inherits them; and ordinary access control, on the principle that if an agent should never touch production, the developer's machine should not hold production credentials.

Rolling it out

The suggested rollout starts small: deny rules for secrets and allow rules for tests and lint, which alone removes most prompts and the riskiest reads. Commit the file through a normal pull request so the team reviews it like code, treat any prompt approved more than twice a week as a candidate for the shared allow list, and run /status in Claude Code to confirm which settings sources loaded. The guide's closing advice is to review changes to the settings file with the same care as CI configuration, because it decides what every developer's agent can do without asking.

Why it matters

Agentic coding assistants are moving from individual experiments to team-standard tooling, and permission prompts are their primary safety interaction. A committed, reviewed settings file turns those prompts from personal muscle memory into versioned configuration, and deny-wins precedence means the guarantees survive local customization. Equally notable is the candor about limits: permission lists buy consistency and fewer interruptions, not security, and hard guarantees still require sandboxing, hooks and credential hygiene. For teams standardizing on Claude Code, a shared settings file is a low-effort, high-leverage first step.