Safeguard CLI as a Security-Aware Coding Assistant for Developers

The Safeguard CLI is a terminal coding assistant that sits next to your vulnerability data. It can tell you how many critical vulns you have, fix a named CVE in the repo, ask before it writes files or runs commands, and run one turn in CI. Use it alongside a general agent such as OpenCode or T3 Code.

There is one more thing worth knowing up front. 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.

If you are comparing open-source coding agents, you are probably weighing model choice, the interface, and how much the agent may do without asking. Those questions matter. This post adds one more: does the assistant know anything about the security state of the code it is editing? We cover the two tools people most often compare, how the Safeguard CLI works, a step by step walkthrough with real commands, the mistakes we see, and a short FAQ.

OpenCode, T3 Code and the Safeguard CLI side by side

OpenCode

OpenCode describes itself as an open source AI coding agent. You run opencode inside a project folder and work in a terminal interface, and the project also offers a desktop app and an IDE extension. It is MIT licensed, per the LICENSE file in its GitHub repository, and its providers page says it supports 75+ LLM providers plus local models. Before adopting it, read its permissions page: each tool can be set to allow, ask or deny, and most permissions default to allow.

T3 Code

T3 Code is a control surface for coding agents that already run on your machine. You start it with t3, which runs a local server and opens a web app, and it also has desktop and mobile front ends. It is MIT licensed, per its LICENSE file, and it works with Codex, Claude, Cursor, Grok Build, OpenCode and Antigravity through the subscriptions you already have set up. Before adopting it, note that at least one of those agents must be installed and signed in first, and the README describes the project as very early.

The comparison

This table sticks to what each project's own pages say.

The last row is the point of this post. OpenCode and T3 Code are general tools for writing and changing code in whatever direction you point them. The Safeguard CLI assistant is built to work from your organisation's findings.

What a security-aware coding assistant changes

A general agent knows your files. It can read a lockfile and guess which packages look old. What it cannot do on its own is tell you which of those packages carry a critical finding in your organisation's data, or which CVE your security team flagged last week.

The Safeguard CLI assistant has tools for local files and for your Safeguard data. That changes the kind of request you can type. Instead of "update my dependencies", you can ask a question with a real answer:

how many critical vulns do we have

Or give a job with a clear finish line:

fix the lodash CVE in this repo

The first is a question about your security state. The second is a code change scoped to one named problem. A general agent can attempt the second, but it starts without the context of what your scans found. The Safeguard CLI starts from that context.

It also changes what happens after any agent finishes. Whether OpenCode, an agent driven through T3 Code, or a teammate wrote the change, you can scan the folder before you merge and see what the change did to your findings. That is the habit we want to make easy.

On the platform side, Safeguard adds reachability analysis, policies and gates, autonomous remediation with fix PRs (off by default), MCP Guardrail, and SBOM and dependency scanning. The CLI does the local work; policies and gates are evaluated in the platform, not by the CLI.

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 platform, and includes an assistant that can fix what it finds. It writes code, not only scans. Here is how each part works.

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, so there is no Node, Python or JVM to install first. It runs on macOS, Linux and Windows, on x86_64 or arm64. Windows is x86_64 only.

Your first session

Run safeguard with no arguments to open the interactive terminal. Type /login and approve the sign-in in your browser. Then scan the folder you are in:

/scan .

From there you talk to it in plain language. Ask questions about your findings, ask it to explain a result, or ask it to fix something. Type @ to attach a file from the folder you started in, so the assistant reads exactly the manifest or config you mean. If you close the terminal halfway through, /resume picks up the last session in that folder.

Writing and fixing code

The assistant can write files, edit code and run commands. That is what lets it go from "you have a vulnerable lodash" to a code change you can review. A good prompt names the problem and the scope: one CVE, one package, one folder. After a fix, scan again so you can see the result rather than take it on trust.

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.

If you already use T3 Code to drive agents through subscriptions you have, the idea is familiar. You keep the model plan you chose and add security context on top. /model shows or switches the AI model; see the CLI docs for connecting a model.

Approvals: Ask, Auto and Yolo

Writing files, editing code and running commands all ask before they act. /permissions sets the approval mode:

Use Ask in a repo you do not know well. Auto suits daily work. Keep Yolo for throwaway environments where you accept every action in advance.

CI with safeguard exec

safeguard exec runs one non-interactive assistant turn, which fits a CI step:

safeguard exec "summarise the critical findings in this repository"

For scans in a pipeline, safeguard scan builds an SBOM and matches it against vulnerability databases. Point it at what you have:

safeguard scan --dir .
safeguard scan --repo <url>
safeguard scan --image <name>
safeguard scan --sbom <file>

Results are JSON files under ./output, including vuln.json and license.json. safeguard validate checks CycloneDX, SPDX and VEX documents.

Where your source goes

When the local runner runs platform scan jobs, your source code never leaves the machine. Only SBOMs and findings are uploaded.

Step by step: from install to a fixed CVE

This walkthrough uses only the commands above. Swap in your own repo and CVE.

Step 1: install and check you are signed in

Install with the one-line command for your platform, open a terminal in the repo you care about, and run:

safeguard

Type /login, approve in the browser, and come back to the terminal.

Step 2: choose your approval mode

For a first session, pick Ask so you see every action before it happens:

/permissions

You can move to Auto once you are comfortable with what the assistant does in this repo.

Step 3: choose your model

Run /model to see the current model or switch. If you want to use your Claude or ChatGPT plan, connect it as the CLI docs describe.

Step 4: get a baseline

/scan .

Then ask the question you would otherwise answer by clicking through a dashboard:

how many critical vulns do we have

Write down the number. It is your before.

Step 5: fix one named problem

fix the lodash CVE in this repo

In Ask mode the assistant asks before each file write or command. Read each one. If it wants to edit a manifest you did not expect, say no and ask why.

Step 6: confirm the change

Scan again:

/scan .

Ask the same question as in step 4 and compare. If the number did not move, ask the assistant to explain what is still flagged.

Worked example: checking another agent's work

Say you used OpenCode or an agent in T3 Code to add a feature, and it pulled in a new dependency. Before you merge, run a scan from the repo root:

safeguard scan --dir .

Open ./output/vuln.json to see what the scan matched. Then open safeguard, type @, attach the manifest the other agent changed, and ask what the new dependency introduced. If something needs fixing, ask for that fix by name.

Worked example: a container image

If you ship a container, scan the image too, since the base image brings its own packages:

safeguard scan --image <name>

The results land under ./output in the same JSON form.

Worked example: an SBOM from a supplier

If a supplier sends you an SBOM, check that it is a valid CycloneDX or SPDX document with safeguard validate, then scan it:

safeguard scan --sbom <file>

Worked example: a CI summary

Add a step that scans the checkout and asks for a summary a reviewer can read:

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

Check the CLI docs for how to sign in on a CI runner before you wire this up. Pass or fail decisions belong to policies and gates in the platform, so treat this step as information for the reviewer.

Use it alongside a general agent, not instead of one

The Safeguard CLI is not a feature-for-feature replacement for OpenCode, T3 Code or any other coding agent. It does not need to be.

Keep your general agent for broad feature work: new endpoints, refactors, UI changes, tests. That is what those tools are built for, and you may already have the setup and the habits.

Reach for the Safeguard CLI when the task is about security state:

• You want to know what is critical right now before deciding what to work on.
• A specific CVE needs fixing and you want an assistant that can see your findings.
• Another agent has just changed dependencies, and you want a scan before you merge.
• You want a CI step that summarises critical findings for the reviewer.

The two fit in one workflow. One agent writes the feature. The Safeguard CLI checks what changed and fixes what it finds. Policies and gates in the platform decide whether it ships. And because you can use your Claude or ChatGPT plan inside the Safeguard CLI with no extra Safeguard charge, adding it does not mean paying for a second model plan.

Common mistakes

Starting in Yolo. Yolo approves everything. In a repo you have not worked in with the assistant before, start in Ask, then move to Auto.

Asking for "fix all the vulnerabilities". A broad prompt produces a broad diff that is hard to review. Name one CVE or one package per request, scan, then move on.

Skipping the second scan. A fix is a claim until a scan confirms it. Run /scan . or safeguard scan --dir . after every change.

Scanning only the code. If you ship a container image, scan the image as well, using safeguard scan --image with the image name.

Expecting the CLI to block a merge. Policies and gates are evaluated in the platform, not by the CLI. Use safeguard exec in CI for a summary, and set gates in the platform.

Reading too much into "source stays local". The docs say source never leaves the machine when the local runner runs platform scan jobs. That statement is about scan jobs. Check the docs for anything else you rely on.

Forgetting your plan's limits. Safeguard adds no extra charge when you use your Claude or ChatGPT plan, but your plan's own usage limits and terms still apply.

FAQ

What can the Safeguard CLI scan?

A folder with --dir, a Git repository with --repo, a container image with --image, or an existing SBOM with --sbom. Each scan builds an SBOM and matches it against vulnerability databases.

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. Use /model and the CLI docs to connect a model.

Does the Safeguard CLI write code or only scan?

It writes code. The assistant can write files, edit code and run commands, and those actions ask before they act.

What is the default approval mode?

Auto. It approves known actions and asks for anything new. /permissions switches to Ask or Yolo.

Does my source code get uploaded?

When the local runner runs platform scan jobs, source code never leaves your machine. Only SBOMs and findings are uploaded.

Can I run it in CI?

Yes. safeguard exec runs one non-interactive assistant turn, and safeguard scan writes its results as JSON under ./output.

Should I replace OpenCode or T3 Code with it?

Not necessarily. Use your general agent for feature work and the Safeguard CLI for security questions, named CVE fixes and scans before merge.

What operating systems does it support?

macOS, Linux and Windows, on x86_64 or arm64. Windows is x86_64 only.

Ready to try it? Install from safeguard.sh/download and start with the CLI docs.

Try it yourself

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

Quick check

Sources

• Safeguard CLI documentation
• Safeguard CLI slash commands
• Safeguard CLI interactive terminal
• OpenCode repository on GitHub
• OpenCode LICENSE file
• OpenCode documentation
• OpenCode providers
• OpenCode permissions
• T3 Code repository on GitHub
• T3 Code LICENSE file
• T3 Code permission modes

Last reviewed: 20 October 2026.