Team Permission Profiles

When five developers on the same team each configure their own permissions independently, you get five different safety profiles. Developer A auto-accepts everything because speed matters. Developer B gates everything because they once lost data. Developer C has not configured permissions at all and runs the default. The result is inconsistent safety across the team — the codebase is only as safe as the least careful developer's configuration.

The fix is a shared permission baseline committed to settings.json in the project. This file defines what the team agrees is safe to auto-accept, what must be gated, and what is outright denied. Individual developers can add stricter rules via settings.local.json, but they cannot weaken the team baseline. This is the same principle as branch protection rules in Git — the team sets the floor, individuals can raise it but never lower it.

Onboarding a new developer becomes trivial. They clone the repo, launch Claude Code, and immediately inherit the team's permission profile. No manual configuration. No "read the wiki and set up your permissions." No risk of a new hire accidentally auto-accepting destructive commands because they did not know the codebase well enough to configure permissions correctly. The shared baseline makes safety a default, not an opt-in.