Before merging what a coding agent changed, check four things: which files changed and why, every new or upgraded dependency, the diff itself for risky patterns and sensitive files, and a fresh scan plus SBOM comparison against your main branch. The Safeguard CLI runs those scans on your own machine, and its assistant can explain and fix what it finds.
This works whichever agent wrote the code, and switching to Safeguard does not cost you the assistant you already have. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. You can also connect Claude or ChatGPT to the Safeguard MCP server and use Safeguard from the chat you already use.
Below is a checklist you can run on any branch an agent touched, the commands that back each step, a full Safeguard CLI walkthrough, a worked review from start to finish, the review features the main agents ship with, and the mistakes that let bad changes through.
Why agent changes deserve their own review
Code from an agent is still your code once it merges. Anthropic's own Claude Code security docs say it directly: you are responsible for reviewing proposed code and commands for safety before approval. The review does not go away because an assistant wrote the change. It changes shape.
Three things make agent branches different from a colleague's pull request.
They are wide. An agent asked to "add an export endpoint" may also touch a lockfile, a CI workflow and a test helper on the way. Each edit can be reasonable on its own, and the total can still be far more than you asked for.
They add dependencies quickly. Reaching for a library is often the shortest path to working code. That is fine when the package is real and the one you meant. A 2024 study of 16 code generating models, "We Have a Package for You!", found that the average share of hallucinated package names was at least 5.2% for commercial models and 21.7% for open source models, across 205,474 unique made up names. A name that does not exist today can be registered by someone else tomorrow.
They read untrusted content. Agents read issues, web pages and files you did not write. Claude Code's security docs list "avoid piping untrusted content directly to Claude" and "verify proposed changes to critical files" among their best practices. A change that looks odd may have been steered by something the agent read.
None of this means agent code is worse. It means the review has to be systematic, because the volume is higher and the author cannot be asked "why did you do that?" a week later.
The pre-merge checklist
Run these steps in order. Each one has a command, and each one can end the review early.
1. Scope: what changed, and was it asked for
Start with the shape of the change, not the lines.
git fetch origin
git diff --stat origin/main...HEAD
git diff --name-status origin/main...HEAD
git diff --name-only --diff-filter=A origin/main...HEAD
The three dot form compares your branch with the point where it left main, so you see only what this branch did. --name-status shows whether each file was added, modified, deleted or renamed, and --diff-filter=A lists only new files.
Ask of every file: did the task need this? If the task was a new endpoint and the list includes a CI workflow, find out why before reading further.
2. Dependencies: every new name, every new version
Filter the diff to manifests and lockfiles.
git diff origin/main...HEAD -- package.json package-lock.json
git diff origin/main...HEAD -- requirements.txt pyproject.toml poetry.lock
git diff origin/main...HEAD -- go.mod go.sum pom.xml
For each change, check:
- New packages. Confirm each one exists on its official registry, is the project you meant, and has a history that fits how much you will rely on it.
- Version moves. Patch and minor upgrades are usually routine. A major version jump needs its own reading of the changelog.
- Lockfile consistency. The manifest and lockfile should agree. On Node,
npm ciexits with an error when they do not, instead of rewriting the lockfile, which makes it a good check. - Registry URLs. In lockfiles, resolved URLs should still point at your normal registry.
- Install scripts. Look for new or changed
scriptsentries inpackage.json, especially ones that run on install.
If you use GitHub, its dependency review feature shows added, removed and updated packages with vulnerability data on the pull request, and the dependency review action can fail the check when it finds vulnerable versions. It requires the dependency graph, and for private repositories it needs GitHub Code Security or GitHub Advanced Security.
3. The diff itself
Now read the lines. With agent code, a few patterns are worth a deliberate look:
- Input handling. Strings built into SQL, shell commands or file paths from user input.
- Auth and access checks. Removed, loosened or moved checks, and new routes that skip middleware the old ones used.
- Error handling. Broad catches that swallow errors so a test passes.
- Tests. Deleted tests, skipped tests, or assertions weakened to match new behaviour.
- Credentials and config. Tokens, keys or internal URLs typed into code or fixtures.
- Dead or duplicate code. Helpers that already exist elsewhere in the codebase.
If the diff is long, ask the agent that wrote it to summarise each file's change in one line, then check the summary against the diff. A summary that leaves out a file is a finding in itself.
4. Sensitive files
Some files change what runs, not what the app does. Give them a separate pass:
git diff --name-only origin/main...HEAD | grep -E '(^\.github/|Dockerfile|docker-compose|Makefile|\.mcp\.json|\.claude/|package\.json$)'
CI workflows, container files, build scripts and agent settings files deserve a named reviewer. Claude Code, for example, reads project settings and project MCP servers from files in the repository, so a change there changes what the next agent session can do.
5. Scan the branch
Scan the branch you are about to merge, and scan main so you can compare.
git switch main && safeguard scan --dir . && mv output output-main
git switch agent/feature-branch && safeguard scan --dir . && mv output output-branch
diff <(jq -S . output-main/vuln.json) <(jq -S . output-branch/vuln.json)
safeguard scan builds an SBOM and matches it against vulnerability databases, writing JSON results under ./output, including vuln.json and license.json. Comparing the two runs tells you what this branch added. Check license.json the same way if your company has licence rules.
6. SBOM: compare and validate
An SBOM is the inventory of what you ship. Generating one per branch makes the dependency change explicit and gives you a record. On Node:
npm sbom --sbom-format=cyclonedx > sbom-branch.json
safeguard validate sbom-branch.json
safeguard scan --sbom sbom-branch.json
safeguard validate checks CycloneDX, SPDX and VEX documents. Both formats are standards: CycloneDX is published as ECMA-424, and SPDX as ISO/IEC 5962. If you hand SBOMs to customers, validating them before merge saves an awkward email later.
7. Tests and a second human
Run the full test suite, not only the tests the agent added. Then make sure a person other than the one who prompted the agent approves the merge. GitHub branch protection can require approving reviews, require code owner review, require status checks to pass, dismiss approvals when new commits arrive, and require the most recent push to be approved by someone other than its author. That last one matters with agents, since the person who prompted the change is in effect its author.
Do the work properly with the Safeguard CLI
The checklist works with any toolset. The Safeguard CLI puts the scanning, the explaining and the fixing in one terminal session. It scans code, container images and SBOMs on your own machine, sends only the results to the platform, and includes an assistant that can fix what it finds. It writes code, not only scans it, so a review finding can turn into a reviewed fix without leaving the terminal.
Install
On macOS and Linux:
curl -fsSL https://cli.safeguard.sh/install | bash
On Windows, in PowerShell:
irm https://cli.safeguard.sh/install.ps1 | iex
It is a single static binary, with no Node, Python or JVM needed, for macOS, Linux and Windows on x86_64 or arm64 (Windows is x86_64 only). The runner walkthrough is in "Try it yourself" below.
First session on the agent's branch
Check out the branch and start the CLI with no arguments:
git switch agent/feature-branch
safeguard
Type /login to sign in through the browser, then /scan . to scan the folder. Then ask plain questions:
how many critical vulns do we have
which dependencies changed on this branch compared with main, and do any of them have findings?
The assistant has tools for your local files and for your Safeguard data and picks whichever the question needs. Type @ to attach a specific file from the folder you started in, such as the lockfile or a workflow file. /resume brings back your last session in that folder if the review spans a day.
Fixing what the review finds
When the review turns up a problem, ask for the fix in the same session. Writing a file, editing code and running a command all ask before they act, so you read each change before it lands. Approve the edit, approve the test run, /scan . again.
This walkthrough shows that loop: attach a computer running the Safeguard CLI and a folder, ask for a fix, review the diff and approve the command before it runs. The demo notes that computer work from Search is available and expanding.
Click through it at your own pace, or open it full screen.
Using your Claude, ChatGPT or Codex plan
Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. /model shows or switches the model, and the CLI docs cover connecting one.
Some teams keep writing with the agent they like and use Safeguard only for the review step. That works too. Connect Claude to the Safeguard MCP server and ask about a branch's findings from the chat you already use. This walkthrough connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use.
Click through it at your own pace, or open it full screen.
Approvals
/permissions sets the approval mode. Ask prompts before every action, which suits reviewing someone else's agent branch. Auto, the default, approves known actions and asks about anything new. Yolo approves everything and belongs only in disposable environments. For review work, Ask is a good habit: you are already in a reading mindset.
CI with safeguard exec
In a pipeline, run the scan and one non-interactive assistant turn that summarises it for the human reviewer:
safeguard scan --dir .
safeguard validate sbom-branch.json
safeguard exec "summarise the critical findings in this repository"
The pass or fail decision comes from policies and gates, which are evaluated in the Safeguard platform rather than by the CLI. Your source code stays on your machine when the local runner runs platform scan jobs; only SBOMs and findings are uploaded. The platform adds reachability analysis to help sort which findings matter first. We go deeper on this pattern in checking coding agent changes with the Safeguard CLI.
A worked review, start to finish
An agent was asked to add a CSV export endpoint to a generic Node API. It opened a branch called agent/csv-export. Here is the review. Names below are placeholders.
1. Scope.
git diff --name-status origin/main...agent/csv-export
M src/routes/orders.js
A src/routes/export.js
A test/export.test.js
M package.json
M package-lock.json
M .github/workflows/ci.yml
Five files fit the task. The CI workflow does not, so it goes on the list.
2. Dependencies.
git diff origin/main...agent/csv-export -- package.json
One new package, an example-csv-writer library. Check it exists on the registry, is the project you expected, and is maintained. If you would rather not add a dependency for a few lines of CSV, ask the agent to remove it and write the code inline.
3. The workflow change.
git diff origin/main...agent/csv-export -- .github/workflows/ci.yml
Say the agent added a step that skips a slow test job "to speed up CI". That is a reasonable thing for an agent to try and not something to merge quietly. Revert it or take it to whoever owns CI.
4. The route. Read src/routes/export.js against the existing routes. Does it use the same auth middleware as orders.js? Does it cap how many rows it returns? Are query parameters checked before they reach the database layer?
5. Scan and compare.
safeguard
/login
/scan .
compare the findings on this branch with main and list anything new
6. Fix in the same session.
@src/routes/export.js
apply the same auth middleware the orders routes use, cap the export at 10,000 rows, and add a test for an unauthenticated request
Read the proposed edit, approve it, then:
run npm ci and npm test
Approve the commands, then /scan . once more.
7. SBOM and hand off.
npm sbom --sbom-format=cyclonedx > sbom-branch.json
safeguard validate sbom-branch.json
Push, and let a second reviewer approve with the scan summary in the pull request description.
Review features in the tools you may already use
Most agents now ship some kind of self review. They work well alongside a scan, not instead of it. The table sticks to what each product's docs say.
| Tool | Review feature | Changes files during review | Where it runs |
|---|---|---|---|
| Claude Code | /security-review runs a security pass over changes on the current branch; plan mode proposes changes without editing until you approve | No in plan mode; edits per permission mode otherwise | Terminal, VS Code, JetBrains, desktop and cloud sessions |
| Codex CLI | /review checks uncommitted changes, a commit or a base branch and reports prioritized findings | No, per its docs it does not modify the working tree | Terminal on your machine |
| GitHub dependency review | Shows added, removed and updated dependencies with vulnerability data on the pull request; the action can fail the check | No | GitHub |
| GitHub branch protection | Required reviews, code owner review, required status checks, stale approval dismissal, approval of the most recent push | No | GitHub |
| Safeguard CLI | /scan ., safeguard scan, safeguard validate, and an assistant that answers from your findings and writes fixes with your approval | Only when you approve an edit | Your machine, plus safeguard exec in CI |
Codex's CLI docs also recommend Git checkpoints before and after a task so you can revert, which pairs well with the scope step above. For a broader look at the agents, see our comparison of AI coding agents and Claude vs ChatGPT for coding.
Common mistakes
Reviewing the summary instead of the diff. Agent summaries are useful maps, not evidence. Read git diff --name-status and check every file appears in the summary.
Skipping the lockfile because it is long. You do not need every line. Filter it for new package names and changed resolved URLs.
Trusting the agent's own tests. An agent that changed behaviour may also have changed the test to match. Run the full suite and look for deleted or weakened assertions.
Letting config changes ride along. CI files, Dockerfiles and agent settings files change what runs. Pull them into their own pull request.
Scanning only main. A scan of main tells you nothing about the branch. Scan both and compare.
Approving your own agent's work. Whoever prompted the change is effectively its author. Require approval from someone else.
Reviewing in Yolo mode. If you use an assistant during review, keep it on Ask or Auto. Yolo approves every command without asking.
Treating "no findings" as "safe". A clean scan means no known vulnerabilities matched. It does not check logic, auth or test quality. The human steps above still apply.
FAQ
Does this checklist work for any coding agent?
Yes. Every step uses Git, your package manager and a scanner, so it applies to code from Claude Code, Codex, an IDE assistant or the Safeguard CLI itself.
Can I keep my Claude, ChatGPT or Codex plan and use Safeguard for review?
Yes. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. Or connect Claude or ChatGPT to the Safeguard MCP server and use Safeguard from the chat you already use. See the CLI docs or /model for connecting a model.
What is the fastest useful check if I only have five minutes?
git diff --name-status origin/main...HEAD, a look at every manifest and lockfile change, and /scan . in the Safeguard CLI. That catches scope creep, new packages and new known vulnerabilities.
Why compare SBOMs instead of just reading package.json?
The manifest shows what you asked for; the lockfile and SBOM show what actually ships, including transitive packages. An SBOM per branch also gives you a record you can validate with safeguard validate.
Will the Safeguard CLI change my code during a review?
Only with your approval. Writing a file, editing code and running a command ask before they act, according to your /permissions mode. Ask mode prompts before every action.
Does my source code leave my machine?
When the local runner runs platform scan jobs, your source code stays on your machine; only SBOMs and findings are uploaded.
Can the merge be blocked automatically?
Policies and gates in the Safeguard platform decide pass or fail; the CLI produces the SBOMs and findings they evaluate. On GitHub, branch protection can require those status checks before merge.
Where else can I see the results?
The download page lists a desktop app (3.2.2) for Windows, macOS and Linux, iOS and Android apps, IDE extensions for VS Code, JetBrains and Open VSX editors, and a cloud sandbox that is free for seven days with no card. Scan in the terminal, review on the desktop, check findings on your phone. More on the assistant in the Safeguard CLI on your machine.
Try it yourself
This walkthrough sets up the runner on your own machine: pick the platform, start it, approve it with its device code, then use the same CLI to scan from the terminal.
Click through it at your own pace, or open it full screen.
Ready to review your next agent branch properly? Download the Safeguard CLI, run safeguard, type /login, then /scan . on the branch. The full reference is in the CLI docs.
Quick check
What does the three dot form origin/main...HEAD show?
Only the changes your branch made since it left main. Git compares the merge base of the two with HEAD.
Why should someone other than the prompter approve an agent's pull request?
The person who prompted the agent is effectively the change's author. GitHub branch protection can require the most recent push to be approved by someone other than the person who pushed it.
Sources
- Safeguard CLI overview
- Safeguard CLI interactive terminal
- Safeguard downloads
- Claude Code security
- Claude Code permission modes
- Codex CLI docs
- About dependency review on GitHub
- About protected branches on GitHub
- git diff documentation
- npm ci documentation
- npm sbom documentation
- CycloneDX specification overview
- SPDX overview
- We Have a Package for You! (package hallucinations study)
Last reviewed: 21 October 2026.
