How to Check What a Coding Agent Changed with the Safeguard CLI

To check what an open-source coding agent changed, scan the repository with the Safeguard CLI before the session, let the agent work, then scan again and compare the two vuln.json files. Anything new came from the session. Ask the Safeguard assistant to fix it with approval set to Ask, then run a final check in CI.

You can also bring the Claude or ChatGPT 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. So the assistant that checks your agent's work can run on the subscription you already have.

This guide is long on purpose. It covers the tools involved, how to set up the Safeguard CLI, a step by step walkthrough with what to check at each stage, worked examples, the mistakes we see most often and a FAQ.

Why check what an agent changed

A coding agent can add a dependency, bump a version or pull in a new transitive package while it works on something else entirely. You asked for a date picker and it added a date library. You asked it to fix a failing test and it upgraded a test runner. The code diff shows the lines it touched. It does not tell you whether a package it added has a known vulnerability, or whether a version it bumped moved you onto a release with one.

That is the gap a before and after scan closes. You record your vulnerability picture before the session, record it again after, and the difference is what the session did to your dependency risk. You can then fix only what is new, with an assistant that can see both the findings and your code.

The method works with any agent. Two open-source ones come up often.

OpenCode describes itself as "the open source coding agent." It runs as a terminal interface, a desktop app (in beta) and an IDE extension. Its site says you can connect models from many providers, including local models, or log in with an existing subscription such as GitHub Copilot or ChatGPT Plus or Pro. It is MIT licensed. Before adopting it, note that its default build agent is described as full access, while the plan agent is read only and asks before running bash commands. If you keep provider keys in its hosted console, read our write-up on rotating provider keys after the OpenCode Console incident.

T3 Code calls itself an "agent harness control surface." It is a desktop, web and mobile app, plus a small command line launcher, that controls agents already running on your machine, such as Claude Code, Codex, Cursor and OpenCode, using your existing subscriptions to those tools. It is MIT licensed. The project says it is very early, that you should expect bugs, and that it is mostly not accepting contributions yet.

How the three tools compare

This table sticks to what each project's own pages say. It is not a ranking. The tools do different jobs and work well side by side.

The last row is the point of this guide. Your agent writes the code. The Safeguard CLI tells you what that code did to your risk, and can fix it.

Do the work properly with the Safeguard CLI

The Safeguard CLI scans code, container images and SBOMs on your own machine, sends only the results to the Safeguard platform, and includes an assistant that can fix what it finds. It writes code too, not only scans. That combination is what makes it a good partner for any coding agent: it can look at your findings and your files in the same session.

Install

The CLI is a single static binary. You do not need Node, Python or a JVM. It runs on macOS, Linux and Windows, on x86_64 or arm64. On Windows it is x86_64 only.

On macOS or Linux:

curl -fsSL https://cli.safeguard.sh/install | bash

On Windows, in PowerShell:

irm https://cli.safeguard.sh/install.ps1 | iex

First session

Run the command with no arguments to open the interactive terminal:

safeguard

Inside it, sign in through your browser, then scan the folder you started in:

/login
/scan .

From there you can ask questions in plain language. Two that work well on day one:

how many critical vulns do we have
fix the lodash CVE in this repo

The @ key attaches a file from the folder you started in, which is how you point the assistant at a specific manifest or scan result. /resume picks up the last session in that folder, so you can stop and come back.

Writing and fixing code

The assistant has tools for your local files and for your Safeguard data. It can write files, edit code and run commands. That is the difference from a scanner that only reports: you can ask it to make the fix, and it makes the change in your working copy for you to review.

Because it can see your findings, you do not have to copy a CVE into a chat window and explain your project. You ask it to fix what the scan found and it works from the scan.

Using your Claude or ChatGPT plan

Bring the Claude or ChatGPT 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. This is the same idea as OpenCode and T3 Code letting you use your existing subscriptions.

To see which model the CLI is using, or to switch, run:

/model

For connecting a model to your plan, follow the Safeguard CLI docs or the /model command itself.

Approvals

Every file write, code edit and command the assistant wants to run asks before it acts. /permissions sets how often it asks:

• Ask prompts before every action.
• Auto approves known actions and asks for anything new. This is the default.
• Yolo approves everything.

When you are reviewing what another agent did, use Ask. You want to see each change, not just the end result.

CI with safeguard exec

For pipelines, safeguard exec runs one non-interactive assistant turn. Pair it with a scan:

safeguard scan --dir .
safeguard exec "summarise the critical findings in this repository"

The summary lands in your build log. If you want a build to pass or fail on findings, use policies and gates, which are evaluated in the Safeguard platform rather than by the CLI. The platform also offers autonomous remediation with fix pull requests, which is off by default.

Beyond one folder

The same binary scans more than a working directory:

safeguard scan --repo <url>
safeguard scan --image <name>
safeguard scan --sbom <file>
safeguard validate

These scan a repository by URL, a container image and an existing SBOM file. The validate command checks CycloneDX, SPDX and VEX documents. When the local runner runs platform scan jobs, your source code never leaves the machine; only SBOMs and findings are uploaded.

Ready to try it? Download the Safeguard CLI and run your first baseline scan before your next agent session.

The walkthrough, step by step

Each step below says what you should see, what to check, and what to do if it goes wrong.

Step 1: Install and sign in

Run the install command for your platform from the section above, then run safeguard and type /login.

What you see. The interactive terminal opens. /login sends you to your browser to sign in.

What to check. Run a quick question such as "how many critical vulns do we have". An answer drawn from your Safeguard data means you are signed in to the right account.

If it goes wrong. If your shell cannot find the command right after install, open a new terminal window so it picks up the new binary. On Windows, check you are on an x86_64 machine, since arm64 is not supported there. If sign-in does not complete, run /login again.

Step 2: Start from a clean tree

Before the agent touches anything, make sure the only changes you will compare later are the agent's.

git status
git stash

What to check. git status should report a clean working tree. If you have work in progress, commit it or stash it.

If it goes wrong. If you skip this, your own half-finished changes end up in the comparison and you will chase findings the agent did not cause.

Step 3: Take the baseline scan

From the repository root:

safeguard scan --dir .

This builds an SBOM for the folder and matches it against vulnerability databases.

What you see. Results as JSON files under ./output, including vuln.json and license.json.

What to check. Confirm output/vuln.json exists. Then copy it somewhere the next scan will not touch:

mkdir -p .safeguard-baseline
cp output/vuln.json .safeguard-baseline/vuln.json
cp output/license.json .safeguard-baseline/license.json

Keeping license.json too lets you spot a new licence you would rather not ship, not only new vulnerabilities.

If it goes wrong. If there is no output folder, check you ran the scan from the repository root and not a parent folder. The output folder is relative to where you run the command.

Step 4: Let the agent work

Open OpenCode, T3 Code or whichever agent you use and give it the task. Review its code diff as you normally would. Pay extra attention to manifests and lockfiles, since that is where new packages appear.

git diff --stat

What to check. Look for changes to files such as package.json, a lockfile, requirements.txt, go.mod or a Dockerfile. Those are the changes most likely to move your findings.

Step 5: Scan again and compare

From the same folder:

safeguard scan --dir .
diff .safeguard-baseline/vuln.json output/vuln.json

What you see. A plain diff of the two files. If nothing changed, the session did not move your vulnerability findings.

What to check. A raw JSON diff can be noisy. The easier route is to ask the assistant. Open the interactive terminal in the same folder and attach both files with @:

Compare @.safeguard-baseline/vuln.json with @output/vuln.json and list the vulnerabilities that are only in the second file, with the package each one comes from.

Read the answer next to the agent's diff. A new finding usually lines up with a new or changed package, which tells you which part of the session to look at.

If it goes wrong. If @ cannot find the files, you started the CLI in a different folder. Quit, change to the repository root and start it again.

Step 6: Fix new findings with approval on Ask

Set approvals before you ask for any change:

/permissions

Choose Ask. Then:

Fix the vulnerabilities that are in @output/vuln.json but not in @.safeguard-baseline/vuln.json. Explain each change before you make it.

What you see. The assistant asks before each file write, code edit or command.

What to check. Read each proposed change. Approve the ones you understand and reject the rest. Then scan again and confirm the new findings are gone:

safeguard scan --dir .

If it goes wrong. If a fix breaks your build or tests, reject it, tell the assistant what failed and ask for another approach. If you stop halfway, /resume picks up where you left off.

Step 7: Add the CI check

Add the scan and exec commands from the CI subsection above to your pipeline, so every branch gets the same look before merge. How you sign the CLI in on a build runner depends on your pipeline; follow the Safeguard CLI docs.

Worked examples

Example 1: An OpenCode session that adds a package

You ask OpenCode's build agent to add CSV export to a Node service. It adds a CSV library and updates the lockfile.

git status
safeguard scan --dir .
mkdir -p .safeguard-baseline && cp output/vuln.json .safeguard-baseline/vuln.json
# run your OpenCode session here
git diff --stat
safeguard scan --dir .
diff .safeguard-baseline/vuln.json output/vuln.json

Then in the Safeguard terminal, with /permissions on Ask:

Which findings in @output/vuln.json are new compared with @.safeguard-baseline/vuln.json, and which new package brought each one in?

If one shows up, ask the assistant to fix it and approve each step. Rescan to confirm.

Example 2: T3 Code driving agents in two checkouts

If you keep separate checkouts for separate agent tasks, scan each one on its own. The output folder is relative to where you run the scan, so results do not mix.

cd ~/code/app-feature-a
safeguard scan --dir .
cd ~/code/app-feature-b
safeguard scan --dir .

Take a baseline in each checkout before its session starts, and compare within that checkout afterwards.

Example 3: The agent edited your Dockerfile

Folder scans cover your dependencies. If the agent changed a base image or added system packages, scan the image before and after too:

docker build -t myapp:before .
safeguard scan --image myapp:before
# run the agent session, then
docker build -t myapp:after .
safeguard scan --image myapp:after

Copy output/vuln.json between the two image scans, as in Step 3, so the second does not replace the first.

Example 4: You forgot the baseline

The agent has already finished. If its work is on a branch, scan the main branch in a separate worktree to get a baseline:

git worktree add ../app-baseline main
cd ../app-baseline
safeguard scan --dir .

Then compare that output/vuln.json with the one from your working copy.

Common mistakes

Skipping the baseline. Without a before scan you cannot tell which findings the session added. You end up fixing old issues while new ones slip through.

Scanning from the wrong folder. Results land under ./output relative to where you run the command, and @ only attaches files from the folder you started the CLI in. Run both from the repository root.

Letting the second scan replace the first. Copy vuln.json out of ./output before you scan again.

Reviewing only the code diff. Most new findings come from manifests and lockfiles, which are easy to skim past.

Leaving approvals on Yolo. Yolo approves everything. That is the opposite of what you want when reviewing another agent's work. Use Ask.

Expecting the CLI to block a merge. Policies and gates are evaluated in the Safeguard platform, not by the CLI. Use exec in CI for a summary, and gates for pass or fail.

Committing scan output. Add output and .safeguard-baseline to your .gitignore unless you mean to keep them.

Assuming your plan has no limits. Using your Claude or ChatGPT plan inside the CLI carries no extra Safeguard charge, but your plan's own usage limits and terms still apply.

FAQ

Does the Safeguard CLI replace OpenCode or T3 Code?

No. Use it alongside them. Your agent writes the feature; the Safeguard CLI scans what changed, tells you what is new and can fix it with your approval.

Can I use my Claude or ChatGPT plan inside the Safeguard CLI?

Yes. Bring the Claude or ChatGPT 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. See the CLI docs or /model for connecting a model.

Does my source code leave my machine?

Scans run on your own machine and only the results go to the Safeguard platform. When the local runner runs platform scan jobs, your source code never leaves the machine; only SBOMs and findings are uploaded.

Can the Safeguard CLI write code, or does it only scan?

It writes code. The assistant can write files, edit code and run commands, and each of those actions asks before it acts.

Which approval mode should I use?

Ask, when you are checking another agent's work. Auto is the default and asks only for actions it has not seen before. Yolo approves everything.

Can the CLI fail my CI build?

The exec command runs one assistant turn and writes its answer to your build log. Pass or fail decisions belong to policies and gates in the Safeguard platform.

What else can it scan?

A repository by URL, a container image and an existing SBOM file. It can also validate CycloneDX, SPDX and VEX documents.

Do I need Node or Python installed?

No. It is a single static binary.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard CLI documentation
• OpenCode repository on GitHub (MIT licence)
• OpenCode website
• T3 Code repository on GitHub (MIT licence)

Last reviewed: 20 October 2026.