> ## Documentation Index
> Fetch the complete documentation index at: https://docs.charlielabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Repo Safety

> How to make your repo safe for agents.

Configure your repo so agents and automations can’t merge code without human approval. This is a best practice that teams should follow regardless of whether they use Charlie or not.

<Note>
  This is a customer-configured GitHub control, not a Charlie product guarantee.
  Your organization owns the configuration and GitHub enforces them. Charlie
  cannot bypass GitHub rulesets.
</Note>

## Before you start

* Ensure you have a GitHub team that includes every trusted human who should approve PRs. You can use an existing team, such as `engineering`, or create one.
* Ensure your repo is organization-owned. GitHub's team reviewer requirements are not available for user-owned repos.
* Ensure your GitHub plan and repo type [support rulesets and required reviewers](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets).

## Configure the merge gate

Create a branch ruleset for `main` and any release branches that need the same protection. Configure it to:

1. Require changes to arrive through a pull request.
2. Require one approval from the team with the humans who can approve PRs.

The rule is simple: agents can propose and review code; a human must explicitly approve before it merges.

See GitHub's [ruleset rule reference](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets) for the current controls and reviewer requirements.

## FAQ

### Should we use CODEOWNERS instead?

Use `CODEOWNERS` when the required human reviewer depends on the files changed—for example, require Security for authentication code and Platform for infrastructure. Add the relevant team to `CODEOWNERS`, then enable **Require review from Code Owners** in the ruleset. A code-owner team must be visible and have write access; if multiple owners match, approval from any one of them is sufficient. [GitHub Docs](https://docs.github.com/en/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)

### How do we do this with classic branch protection?

Classic branch protection does not offer direct required-team approval quotas. Put the human team in `CODEOWNERS`—using a catch-all pattern if it should review every PR—and enable **Require review from Code Owners**. [GitHub Docs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)

### Should we dismiss stale approvals?

For stronger protection, enable **Dismiss stale pull request approvals when new commits are pushed**. This invalidates approvals when the reviewed diff changes, requiring a human to approve the updated code. [GitHub Docs](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets)

### What is the trust boundary?

Keep the team used for required reviews human-only, do not give agents bypass or admin permissions, and protect human credentials. GitHub cannot distinguish an agent using a human’s account or token from that human.

### Do auto-merge and merge queue bypass the gate?

No. [Auto-merge](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-auto-merge-for-pull-requests-in-your-repository) waits for merge requirements to pass. A [merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue) also applies the branch's merge requirements. Verify both in your repository because layered rulesets and branch protection can add more conditions.