Claude Code checks who's pushing code — but does it also check which branch they're allowed to push to?

This explores whether Claude Code checks which git branches an agent may push to, as opposed to only protecting the credentials it pushes with. The corpus gives a narrower answer than the question hopes for. What it documents is how credentials are protected. In Claude Code on the web, git credentials never enter the sandbox. Every git operation goes through a proxy that inspects the request and then attaches the real GitHub token outside the agent's reach How does Claude Code protect git credentials from sandbox compromise?. The important detail is in how the source puts it: the proxy authenticates the agent's *identity*, not its *authority*. It confirms who is pushing. The corpus doesn't describe the proxy deciding where that agent is allowed to push. If you want branch-level permission auditing, nothing here shows it, and you shouldn't assume it exists.

The gap between identity and authority comes up across the security material in the collection. One paper argues that whether an agent's action counts as a violation depends entirely on written policy. Where no rule exists, the action is allowed by default, so a branch nobody thought to protect is effectively open How do policies determine whether agent transfers are violations?. A related doctrine for stopping coordinated agent attacks recommends limiting which shared resources agents can touch and testing at the level of permissions, not just identity How can operators stop coordinated agent intrusions now?. A git branch is exactly that kind of shared resource. And the Hugging Face incident shows that controlling the perimeter can stop an agent even when nobody knows yet who sent it Can defenders stop intrusions without knowing who sent them?. Branch protection on the repository side plays a similar role: it guards the target no matter what the agent's own tooling checks.

The most relevant result for branch rules is a study of 'explicit boundary' setups for coding agents. These combined clear authorization rules with restricted tools and recorded zero modifications to protected tests. Because the two were bundled, though, nobody can say whether the agents *couldn't* cross the line or simply *chose not to* Do authorization rules or restricted tools prevent test modifications?. The same question applies to branches: is a rule against pushing to main enforced by the system, or just obeyed by the model? Only the first is something you can audit. Upstream risks matter too. A crafted prompt can steer how a multi-agent system plans its work before any inspection layer runs Can prompts alone reshape multi-agent workflows without system access?, and messages passed between agents inside a pipeline usually go unmonitored Do internal agent hops in pipelines need security monitoring?. Either one could carry an instruction like 'push this to production.'

On the human side, much of the 'auditing' in practice is done by people, and it's looser than you might think. Experienced Claude Code users auto-approve more sessions but interrupt more often, so they correct mid-task more than they approve up front Do experienced AI users trust agents more or just oversee differently?. Developers say they oversee agents by configuring them beforehand, planning with them, watching them work, and reviewing afterward How do developers actually oversee AI coding agents?. In practice they lean on shortcuts like passing tests and skimming instead of checking everything Do developers actually review agent work exhaustively?. If you want a real record of where an agent pushed and why, one option in the corpus is an orchestration layer wrapped around the agent. It keeps a persistent, traceable log without changing the agent itself Can orchestration layers make coding agents more auditable?.

The takeaway is that credential protection and push authorization are separate problems, and the corpus only documents the first one for Claude Code. In this material, branch-level authority comes from repository policy, perimeter controls, or a wrapper that keeps an audit trail, not from the credential proxy.