A company running a large monorepo is considering locking down write access per-directory so only the owning team can push to their own service's folder, mirroring a multi-repo permission model. What are the costs of doing this, and when would you deliberately keep write access repo-wide instead?

## Two different kinds of gate It's useful to separate two different kinds of gate that a monorepo can put on a change, because they operate at different points and carry very different costs. | Gate | Scope | |---|---| | **Review gate** — CODEOWNERS plus a branch-protection rule requiring code-owner approval | Controls whether a change can be merged to the protected branch; it does nothing to stop anyone with ordinary repo access from creating a branch, pushing commits to it, and opening a pull request against any path in the repository. | | **Access gate** — restricting git push itself, or restricting who may even open a PR that touches a given path | Controls something earlier and blunter: whether the change can be proposed against that path at all, regardless of review outcome. | Platforms supporting protected paths or path-based push restrictions implement this second, stricter kind of gate. ## What applying it broadly costs Applying an access gate per project directory sounds like an obviously stronger security posture than review-only, and for a narrow set of paths it is worth it. But applied broadly across a monorepo, it reintroduces almost exactly the coordination cost that using multiple separate repositories carries, which choosing a monorepo was often meant to avoid in the first place. One of the concrete, well-documented benefits organizations cite for adopting a monorepo is the ability to make **atomic, cross-cutting changes**: - renaming a widely-used function; - bumping a vulnerable dependency across every consumer in one commit; - updating a shared interface and all its call sites together so the repository is never in a broken intermediate state. If write access is locked down per directory, none of that is possible without first requesting access into every affected directory, which at organization scale might mean dozens of different teams, turning a single atomic PR into either a slow multi-team access-request process or dozens of separate PRs each waiting on a different team's availability — precisely the coordination tax polyrepos are known for. ## The second system of truth There's also a maintenance cost independent of any specific incident: an access-control list is a second system of ownership truth that has to be kept in sync with CODEOWNERS and with actual team structure, and the two will drift apart independently over time, so an organization running both pays double the upkeep cost for keeping ownership metadata accurate, with twice the surface area for something to be silently wrong. ## What mature practice defaults to Given those costs, most mature monorepo practices default to broad, repo-wide write and push access — any engineer can branch and open a PR anywhere — and rely on the review gate, CODEOWNERS plus branch protection plus build-time boundary enforcement, as the actual control on what lands in the protected branch. This gets almost all of the safety benefit, since nothing merges without the owning team's sign-off, while preserving the monorepo's collaboration and cross-cutting-change benefits, because the expensive step of getting explicit access granted never has to happen for ordinary contribution. ## Where the calculus flips The exception is a genuinely narrow set of paths where the cost calculus flips: - **production secrets and credentials**; - **CI/CD release and deployment pipeline configuration**; - **infrastructure-as-code that defines the security perimeter itself**. For those, the blast radius of a single bad or malicious push — even one that would eventually be caught by review — is large enough, a leaked credential or a compromised release pipeline, that many organizations accept the coordination cost of hard write restriction, sometimes combined with additional controls like required signed commits or a mandatory second approver with no self-approval allowed. The judgment call, made deliberately rather than by default, is: for this specific path, does the cost of a worst-case unreviewed or malicious push exceed the ongoing coordination tax of restricting who can even propose a change here? For the vast majority of an org's code the answer is no; for a small, well-identified set of high-risk paths, the answer is yes.