Checks

Every push is checked before it lands

The push guard decides each push and merge by your rulesets, code graphs are built in isolated containers, every change gets a graph review, and workflows run as checks on your own runners. If the guard can't answer, nothing gets through.

Sign inRead the docs
alice/invoices › Push activity
  • alicemain: 1a2b3c4d → 9c1d22a0allowed
  • release-botagentmain: 9c1d22a0 → 7e4f0b12main is a protected branch: agents can't update itdenied
  • release-botagentagent/export: new → 7e4f0b12allowed
  • bobmain: 9c1d22a0 → 3d8e1f55push guard unavailable, push rejecteddenied

Push guard

A guard on every push and merge

Rulesets for branches and tags decide who may update, delete or force-push, and can require changes, passing checks and deployments, linear history and signed commits. Agents can't update protected branches at all. A ruleset in evaluate mode records what it would have refused, before you enforce it. A site administrator can deny all pushes with a message, for maintenance or an incident.

~/invoices
$ git push origin main
remote: main is a protected branch: agents can't update it (release-bot, acting for alice).
remote: Push another branch and open a change; a person merges it.
 ! [remote rejected] main -> main (pre-receive hook declined)
$ git push origin agent/export
 * [new branch]      agent/export -> agent/export

Fails closed

If the guard can't answer, the answer is no

The git service asks the guard before every push lands. If it can't be reached, the push is rejected and the cause is recorded. A missing check never lets work through unchecked.

~/invoices
$ git push origin main
remote: push guard unavailable, push rejected
 ! [remote rejected] main -> main (pre-receive hook declined)

Graph builds

Built in isolation, byte for byte

Protected branches and change heads are indexed after every push, each build in its own container without access to Branchscope's services or secrets. The same commit always gives the same graph. Builds that hit an infrastructure failure retry on their own.

alice/invoices › Graph builds
  • main 9c1d22a04,212 nodes · 9,876 edgesdone
  • agent/export 7e4f0b12pnpm install --frozen-lockfilerunning
  • fix/totals 3d8e1f55queued

Reviews

A review on every change, as a check

Each change gets a graph review when it's opened and after every push, reported as the check branchscope/review. A ruleset can require it, so a broken rule, or a caller it breaks in another repository, holds back the merge. bscope change review --wait --fail-on deny turns a broken rule into a failing exit code, for a script or an agent.

ci · review
$ bscope change review 7 --wait --fail-on deny
#7 Add invoice creation: review of 1a2b3c4d → 9c1d22a0
1 rule violation, 1 needing review, 0 against the plan.
  Breaks controllers-no-data
    InvoicesController.Create() uses BillingDbContext  InvoicesController.cs:20
bscope: #7: 1 rule violation, 1 needing review
$ echo $?
3

Workflows

CI on your own runners

Workflows in .branchscope/workflows run on a push, a change, a tag, a release, a schedule or by hand, on your organization's own machines. Each job is a check that a ruleset can require before a merge, and agents read why it failed over MCP. Hosted runners in the EU are coming.

acme/invoices › Change #12
  • CI / buildpassed
  • CI / test (node: 24)requiredfailed
  • security-scanrequiredrunning
Merging waits until the required checks have passed.
MergeMerge anyway

Deployments

Deployments that wait for a person

A job with an environment records what runs where, and Deploy again rolls back. A protected environment can take only protected tags, and make the job wait for one of its reviewers and a timer before it starts. Agents can't approve, and by default nobody approves their own run.

acme/invoices › Deployments
  • production v1.4.0Only from protected tags matching v*waiting
  • staging v1.4.0succeeded

deploy deploys to production and is waiting for review by bob, carol. It won't start, or get the environment's secrets, until one of them approves it.

Approve and deployReject

Secrets

Secrets, kept from agents' runs

Repository, organization and environment secrets are encrypted, can't be read back, and are masked in logs. A job gets only the ones it names, and a run an agent set off gets none until a person approves it. For AWS, Google Cloud and Azure, a short-lived identity token replaces a stored key.

acme/invoices › .branchscope/workflows/release.yml
jobs:
  deploy:
    runs-on: deploy
    environment: production
    secrets: [DEPLOY_KEY]
    permissions:
      id-token: write
    steps:
      - run: ./deploy.sh "$BRANCHSCOPE_TAG"

Ask first

Agents can ask before they push

Over MCP, an agent can ask the push guard whether a push, force push or delete would be allowed, with the same answer a real push would get, before it does anything.

Claude Code · branchscope (MCP)
$ check_push { repo: "alice/invoices", branch: "main" }
Not allowed: push to main in alice/invoices. main is a protected branch: agents can't update it.
$ check_push { repo: "alice/invoices", branch: "agent/export" }
Allowed: push to agent/export in alice/invoices.

Put a guard on your next push

Every repository starts with main protected. Sign in, push, and watch the guard's decisions in activity.

Sign in