Keep a human approval step on every AI-written change
Put a person at three gates: approve the scope before the agent writes code, review the pull request it opens, and merge by hand. ProPR builds those gates in, and its agents hold a read-only GitHub token, so ProPR itself makes every branch, commit and pull request and nothing reaches your default branch without a human decision.
Overview
Coding agent tools with manual approval controls: the three gates
Agent output belongs in pull requests, where the team already reviews code. Three gates turn that into a process, and the first is the one most tools skip:
- Scope gate. A person reads what the agent intends to change before it changes anything.
- Review gate. The change arrives as a pull request with your checks, comments and approvals.
- Merge gate. A person merges, or a policy you wrote merges for them.
Behind the gates sits a permission question: who may start the agent at all, and what it can reach while it runs.
Gate 1: approve the plan
Planning shows you the files the model will read, ranked by relevance, before a token is spent. The agent drafts a structured plan with numbered requirements and acceptance criteria; you reorder tasks, ask for different boundaries or more tests, and every refinement saves a version you can restore.
Approval is the handoff. ProPR creates the GitHub issues, you pick the agent per issue, and only then does code start.
Gate 2: review the pull request
The change reaches your team as a normal pull request, with your checks, approvals and merge policy in GitHub. /review posts numbered merge blockers, optional suggestions and a score, and never edits, commits or pushes. /fix F2 S3 applies exactly the findings you name; delete the IDs you disagree with before you post. How review works.
Plain comments become follow-up commits on the same branch, and the assignment gate limits follow-ups to the PR's assignees.
Gate 3: merge by hand
You merge in GitHub. /merge only brings the branch up to date with its base and resolves conflicts; the pull request waits for you. Auto-merge is an opt-in per plan or task, and the auto_merge block in .propr/workflow.yml lists the paths that always wait for a person, whatever the checks say. Repository rules for every run.
What the agent is never allowed to do
- Write to GitHub. The agent's token is read-only; ProPR makes every branch, commit, push and pull request.
- Leave the allowlist, once restricted network mode is on. It is off by default; on, the container reaches only the provider API, GitHub, package registries and the hosts you list.
- Spend past the cap. A run that reaches the per-task, per-repository or instance spend limit stops, and the work so far still arrives as a pull request.
- Merge, deploy, change settings or push code from an Automation. The acting step in Automations works only through ProPR MCP tools and can do none of those.
- Start without permission. Administrators choose who can trigger tasks, which labels and comments count and which agents run, and every role change lands in an audit trail.
Trust and security lays out each boundary.
Which model, prompt and logs produced the pull request
Every task record keeps the exact prompt, the timeline, the agent's reasoning, the changed files, the commits and the model usage, in the web UI and the CLI. The usage log ties each model call to its tokens, cost and duration. Each /review links to its own task record, model and token usage, and the PR template prints the issue, model and cost into every pull request body if you ask it to.
Git objects and GitHub records carry the rest: branch, commits, PR conversation and review scores, ready for clone, grep and diff.
