Let it push to its own branch and open a pull request, and never let it push to a protected branch. Anthropic's routines push to branches prefixed with claude by default, and the docs say branch protection rules and rulesets on GitHub are how you control where a run can push.
What the documentation says
On the routines page: each repository is cloned on every run, Claude starts from the default branch unless the prompt says otherwise, and it pushes work to a branch prefixed with claude unless the prompt directs it elsewhere. To control which branches a run can push to, use branch protection rules or rulesets. For runs on Anthropic managed infrastructure, GitHub applies them to the GitHub access you connected, so a rule that your access can bypass does not block a run's push.
That last point is the one people miss. If the connected identity is an admin who can bypass protection, the automation inherits that bypass.
Rules worth setting
- Protect the default branch. Require pull requests, no direct pushes, no force pushes.
- Require review. At least one human approval from someone other than the author of the change.
- Require status checks. Tests, scans and dependency checks must pass. See required status checks for automated fix pull requests.
- Do not exempt the connected identity. Check that the person or app behind the connection has no bypass.
- Limit repositories. Add only the repositories the task needs, since each is cloned and writable.
- Use a prefix rule. A ruleset that allows creating branches only under the agent prefix keeps experiments contained.
Draft or ready
Have tasks open pull requests as drafts when you can. A draft signals that a human must look first and keeps automatic merge tools away. Whether a particular product supports a draft default is something to confirm in your setup, not assume.
Merge is a separate decision
Pushing a branch is low risk. Merging is where code changes behavior. Keep the merge step human for anything beyond trivial, or gated by environments and approvals as described in human approval before automated remediation. If you do automate merges for narrow categories, define them in advance and measure outcomes.
Reviewing agent pull requests
Reviewers should know a task wrote the change. The branch prefix helps. Ask reviewers to check unexpected files, new dependencies, workflow edits and changes outside the stated scope. Who should review a pull request an agent wrote covers the review.
What not to allow
- Edits to workflow files that run with elevated permissions, unless a person reviews them
- Changes to branch protection or repository settings
- Force pushes
- Writing secrets into the repository
Worked example: from nightly task to merged fix
A team schedules a routine that, each night, scans a repository's dependency manifests for outdated packages and opens a pull request bumping patch versions. Here is how the controls from this post shape the flow.
The routine clones the repository on the default branch and works on a branch named with the claude prefix. It pushes that branch and opens a pull request. The repository has a ruleset on the default branch: pull request required, one approval, status checks for tests and a dependency scan, no force pushes. A second ruleset limits who can create branches under the agent prefix. The identity connected to the routine is a regular developer account, not an administrator, so it has no bypass.
In the morning a reviewer sees a pull request from the connected developer's user on a claude prefixed branch. The label tells them it came from automation. They check the diff: three version bumps, a lockfile change, nothing else. Tests pass. They approve and merge.
One night the routine proposes a change that also edits a workflow file. The ruleset requires code owner review for workflow files, so the pull request cannot merge until the platform team looks. They reject it. The rule worked because it did not depend on anyone remembering to check.
Rules and what each prevents
| Rule | What it prevents |
|---|---|
| Pull request required on default branch | Direct pushes from the agent |
| Required reviewers, code owners for sensitive paths | A change to workflows or deployment config sliding through |
| Required status checks | Merging code that fails tests or scans |
| No bypass for the connected identity | The agent inheriting an admin's override |
| Restrict branch creation to a prefix | Stray branches and tag pushes |
| Block force pushes and deletions | History rewriting |
Checking that your rules actually bind
Do not trust the settings page alone. Test with a throwaway repository: connect the same identity, ask a task to push to the default branch, and confirm it fails. Then check the bypass list. Anthropic's documentation says rules that the connected access can bypass do not block a run's push, so this test is not optional. Record the date and result as evidence.
Writing the prompt to match the rules
Tell the task what it may do: "Push only to a branch named with the claude prefix. Open a draft pull request. Never edit files under the workflows directory. If a fix needs more than three file changes, stop and report." A prompt is not a control, but it reduces noise by aligning intention with enforcement, so rule violations become rare events worth investigating.
When to allow more
If a task proves itself over months, you can relax: auto merge for narrow categories such as patch bumps that pass a defined set of checks. Define the category, write the rollback path, and measure results. Automated fix approval tiers is a good model. Start narrow and widen with evidence.
Where the Safeguard CLI fits
The Safeguard CLI can also write code, and the download page lists a Local agent and a Cloud agent as Available. Whatever tool opens the change, the same branch rules and review steps apply.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which checks block the change and where a human still decides.
Quick check
Does branch protection stop a routine pushing to main?
Only if the connected GitHub access cannot bypass the rule. Check that, since the docs say a bypassable rule does not block the push.
Should a task merge its own pull request?
For most work, no. Keep merge with a human or a defined gate.
Is it safe to let an agent open pull requests at all?
Yes, with branch protection, required review and checks. A pull request is a proposal. The risk is in what can merge without a human, so control that.
Sources
Last reviewed: 19 October 2026.
