Actions

CI that lives where the code does

Workflows in the repository run on your organization's own machines or on hosted runners. Every job is a check on the change, required checks hold back the merge, and agents read the logs and fix what failed.

Workflows

A small format you can read in a minute

A workflow is a YAML file in .branchscope/workflows: triggers, jobs and shell steps, with images, matrices and jobs that wait for each other. It runs on a push, a change, a tag, a release, a schedule or by hand. No expressions to learn and no marketplace to trust. A file with a mistake shows as a failed check, with the line.

acme/invoices › .branchscope/workflows/ci.yml

version: 1
name: CI
on:
  push: { branches: [main] }
  change: {}
jobs:
  test:
    runs-on: linux
    image: node:24
    matrix:
      node: [22, 24]
    steps:
      - run: npm ci
      - run: npm test
  deploy:
    runs-on: deploy
    needs: [test]
    steps:
      - run: ./deploy.sh

Required checks

Required checks hold back the merge

Name the checks a protected branch needs, and a change merges only once they've passed on its latest commit, for people and agents alike. An administrator can merge anyway, giving a reason that stays on the change.

acme/invoices › Change #12

CI / buildpassed
CI / test (node: 24)requiredfailed
security-scanrequiredrunning

Merging waits until the required checks have passed.

MergeMerge anyway

Agents

Agents fix their own builds

Over MCP, an agent waits for its checks, reads why a test failed, pushes a fix and waits again, and hears when checks finish instead of polling. It can never merge past a required check.

claude-code › MCP · agent, for alice, via MCP

$ wait_checks acme/invoices #12
CI / test (node: 24): failed (required) (test failed (exit 1))
$ get_check_log acme/invoices #12 "CI / test (node: 24)"
 ✗ export/csv.test.ts > handles empty rows
$ git push origin agent/csv-export
$ wait_checks acme/invoices #12
The required checks passed.

Runners

CI on your own runners

Run bscope-runner on a server, a VM or the Mac on the desk. It connects out over TLS, takes jobs that match its labels, runs them in containers, and streams the log live. Each job clones with a token that works for that repository only, and only while the job runs.

acme › Runners

$ bscope-runner register --url runners.branchscope.example:443 --token bsc_rrt_… --labels macos,arm64
Registered studio-mac in acme, with labels macos, arm64.

build-1 linux, x64running a job
build-2 linux, x64idle
studio-mac macos, arm64idle

Hosted runners

Or no runner of your own

A job with runs-on: hosted runs on Branchscope's machines, in a Firecracker microVM of its own that's thrown away when the job ends, sized 2cpu, 4cpu or 8cpu. Hosted runners are in early access: a site administrator allows an account or organization first, and sets how many of its hosted jobs run at once.

acme/invoices › .branchscope/workflows/ci.yml

jobs:
  test:
    runs-on: hosted
    size: 4cpu
    image: node:24
    steps:
      - run: npm ci && npm test

size	CPUs	Memory	Disk
2cputhe default	2	4 GB	20 GB
4cpu	4	8 GB	20 GB
8cpu	8	16 GB	20 GB

Push a workflow, watch it run

Add a runner to your organization, put a workflow in .branchscope/workflows, and open a change.