Repo policy: the defaults every front door applies¶

Work reaches hangar through many doors: MCP, REST, the CLI, GitHub issues, Slack, inbound webhooks and schedules. A repo policy is one record per repository with the defaults its jobs get, whichever door they came through. A new kind of intake only has to name the repo.

hangar repo set acme/app --verify "uv run pytest -q" --env python
hangar repo set acme/app --model frontier            # every harness: its provider's strongest model
hangar repo set acme/app --model claude-code=balanced --model codex=gpt-6.1-sol
hangar repo list
hangar repo get acme/app            # the policy, and the environment it falls back to
hangar repo unset acme/app model    # clear one field
hangar repo unset acme/app          # remove the policy
hangar repo set acme/app --job-max-cost 5 --job-max-turns 12 --max-usd-per-day 60
hangar repo set acme/app --land auto_after_approval --approver alice --risk-path 'infra/**'   # docs/landing.md
hangar repo set acme/app --ai-review hangar --self-approval low_risk_with_ai_review       # AI review, self-approval
hangar repo set acme/app --branch-template 'feature/{ticket_key}-{job}' --require-ticket \
  --title-template '{ticket_key}: {title}'                                               # company naming
hangar repo check acme/app          # is it ready for agent work? (below)

The repo is owner/repo for GitHub (any URL form, any case), or the git URL for another host.

Precedence¶

For each field: the job, then the repo's own .hangar/environment.yaml, then the repo's policy, then the environment, then hangar's settings.

• A job's own verify, environment, harness or model always wins.
• A repo's .hangar/environment.yaml can set its verify and, with extends, its environment (within the allowlist). hangar uses the file as the default branch had it at the last clone. See environments.md.
• An environment can carry a verify: too, the fallback for every repo that runs in it:

name: python-app
extends: python
verify: uv run pytest -q

• verify: "" at any level means "no check" and stops the fallback.
• The job's events say what came from the policy (from the repo policy for acme/app: verify …), and verify_source on the job says where its check came from: job, repo or environment.

HANGAR_GITHUB_REPOS stays the allowlist: which repos untrusted and service callers (GitHub, Slack, webhooks, jobs tokens) may start work on, and in which environments. A policy never widens it.

REST¶

Admin tokens only. The repo is a query or body field, because git URLs carry slashes and colons.

Policies are stored in hangar's database, written durably like hangar config settings, and apply to the next job without a restart. Every change is audited (repo.policy.set, .unset, .delete).

Agent scratch files¶

Delivery commits what the agent left, and agents leave notes. hangar keeps these out of the PR, with a narrow rule so it never drops work someone asked for. A file is scratch when all of these hold:

• it is new on the job's branch (a file the base commit has is never touched);
• it is HANDOFF.md, RESULT.md or NOTES.md at the repo root (any case), or a *.orig or *.rej patch leftover anywhere: one next to the file it was made from (a.py.orig beside a.py), so a golden file that only shares the suffix is delivered;
• the task doesn't name it: neither the instructions, any follow-up, nor the context attached to the job mention the file name. Issue and ticket intake put the request in context files, so a file the issue asks for is delivered.

Scratch the agent left uncommitted isn't staged. Scratch it committed itself is removed in a separate commit, hangar: drop agent scratch files, so the change is visible and easy to revert. Either way the file stays in the sandbox, the job's events and result.dropped_files list it, and the PR body says what was left out.

Moved from this page¶