Safeguard CLI Approval Modes: Ask, Auto and Yolo Explained

The Safeguard CLI has three approval modes, set with /permissions. Ask prompts before every action. Auto approves known actions and asks about anything new, and it is the default. Yolo approves everything and never asks. Use Ask on code you care about, Auto for daily work, and Yolo only somewhere disposable.

The modes matter because the assistant in the Safeguard CLI does real work. It writes files, edits code and runs commands on your machine, with your approval, and it also knows your vulnerability data. You can 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. If you prefer to stay in the chat you already use, you can also connect Claude or ChatGPT to the Safeguard MCP server.

This guide covers what each mode does, a worked example for each, how the modes compare with the approval settings in other coding agents, and how a team can agree on which mode to use where.

What the three approval modes do

The Safeguard CLI docs describe the rule simply: "Some tools change things: writing a file, editing code, running a command. Those ask before they act. /permissions chooses how often." The assistant also has tools that read your local files and your Safeguard data. The approval mode is about the tools that change things.

The current mode is always shown in the bar under the input, so you never have to guess which one is active.

Ask

Ask is the most conservative setting. Every write, every code edit and every command stops and waits for you. That sounds slow, and for a long session it is. It is also the only mode where you see every change the assistant wants to make before it happens.

Use Ask when you do not yet know what the assistant will try. The first time you point it at a repository, the first time you ask it to fix a dependency, the first time you let it run your test suite. You learn what it does, and you learn which of its habits you trust.

Auto

Auto is the default. The docs describe it as approving known actions and asking for anything new. In practice that means routine work flows, and the prompts you do see are the ones worth reading, because they are the actions the CLI has not treated as known.

The docs do not publish the list of what counts as known, so do not assume a particular command is on it. Treat every prompt in Auto as a signal: something new is about to happen. Read it before you approve.

Yolo

Yolo approves everything and never asks. It exists because some environments are built to be thrown away: a fresh clone in a container, a VM you rebuild every morning, a cloud sandbox tenant against a seeded demo repo.

Most coding agents ship a mode like this and attach a warning to it. Anthropic's Claude Code docs, for example, list bypassPermissions as "Isolated containers and VMs only." Apply the same rule to Yolo. If losing the folder would hurt, Yolo is the wrong mode.

Switching modes

Type /permissions in the interactive terminal and choose Ask, Auto or Yolo. The bar under the input updates straight away. You can switch in the middle of a session, which is the most useful habit to build: start in Ask while you explore, move to Auto once the plan is clear, and move back to Ask before anything that touches a lockfile, a CI config or a deploy script.

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 writes code and fixes what it finds. The approval modes are what let you hand it real work without handing over control.

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. It runs on macOS, Linux and Windows, on x86_64 or arm64 (Windows is x86_64 only). The download page lists CLI 1.4.0 with builds for macOS Apple Silicon and Intel, Linux x86_64 and arm64, and Windows x86_64.

First session

safeguard            # open the interactive terminal
/login               # sign in through the browser
/permissions         # pick Ask for your first session
/scan .              # scan the folder you started in

Then ask in plain language. The docs give these examples:

how many critical vulns do we have
fix the lodash CVE in this repo
what's the latest file in ~/Downloads

Type @ to attach a file from the folder you started in. /resume picks up the last session in that folder, and /model shows or switches the AI model.

Writing and fixing code

The assistant has tools for your local files and for your Safeguard data, and it picks whichever the question needs. That makes it a general terminal assistant as well as a security one: it can find and read files, edit code and run commands, with your approval. When you ask it to fix a vulnerable dependency, it can see the finding, see the manifest, propose the change and run the command that applies it. Each of those changes goes through the approval mode you chose.

This demo shows the same flow from Safeguard Search: 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 or ChatGPT 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. Use /model to see or switch the model, and see the CLI docs for connecting one. The approval mode works the same whichever model you choose. The model proposes actions; the mode decides whether you are asked.

Approvals

/permissions sets the mode for the session. The three options are the ones in the table above, and Auto is where a new session starts unless you change it. If your team has agreed on a mode for a given repository, set it at the start of the session before the first request.

CI with safeguard exec

safeguard exec "summarise the critical findings in this repository"

safeguard exec runs one non-interactive assistant turn, which is what you want in CI. There is no one at the keyboard to answer a prompt, so give exec jobs that read and report, such as summarising findings, and keep code changes in interactive sessions where a person can approve them. Check the CLI docs for how exec handles approvals in your version before you give it anything that writes.

Scan what changed

safeguard scan --dir .
safeguard scan --repo https://github.com/your-org/your-repo
safeguard scan --image your-image:latest
safeguard scan --sbom ./sbom.cdx.json

Each builds an SBOM and matches it against vulnerability databases, writing JSON files such as vuln.json and license.json under ./output. Scan before and after a session in any mode, and compare the two vuln.json files. safeguard validate 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.

Worked examples for each mode

Three situations, one per mode. The commands are real; the repositories are made up.

Example 1: Ask, fixing a dependency in a payments service

You have joined a team that owns a payments service. The dashboard shows a critical finding in a transitive dependency. You have never worked in this repository.

cd ~/code/payments-service
safeguard
/permissions          # choose Ask
/scan .
which critical findings affect this repo, and which package pulls each one in

The question only reads, so the assistant answers from your Safeguard data and the files in the folder. Now ask for the change:

fix the critical finding in the lodash dependency with the smallest version change

In Ask, every step stops. You see the proposed edit to the manifest and approve it. You see the install command and approve it. If it wants to run the test suite, you see that command too. At each prompt, ask yourself three questions: is this the file I expected, is this the command I expected, and would I be comfortable explaining it in code review.

When it finishes, run /scan . again and confirm the finding is gone and nothing new appeared. Then commit through your normal review process.

Example 2: Auto, a routine afternoon

You know this repository well. You want to update a few dependencies, tidy the README and check your Downloads folder for the SBOM a supplier emailed you.

/permissions          # Auto, the default
what's the latest file in ~/Downloads
check @sbom-supplier.cdx.json against our policy and list anything critical
update the patch versions of our direct dependencies and rerun the tests

Routine actions pass without a prompt, and you get asked when something new comes up. That is the point of Auto. The prompts that do appear deserve more attention than they would in Ask, because you see fewer of them. If one surprises you, decline it, then switch to Ask with /permissions for the rest of that task.

Before you push, run /scan . one more time. Updating dependencies is exactly the kind of change that can add a new vulnerable package, and a scan answers that question directly.

Example 3: Yolo, a disposable container

You want to see how the assistant handles a large upgrade across a monorepo, without sitting through every prompt. You do not want it anywhere near your real checkout.

docker run --rm -it -v "$(mktemp -d)":/work -w /work ubuntu:24.04 bash
apt-get update && apt-get install -y curl git
curl -fsSL https://cli.safeguard.sh/install | bash
git clone https://github.com/your-org/your-monorepo .
safeguard

Inside the session, /login, then /permissions and choose Yolo. Ask for the upgrade. Everything runs without a prompt, inside a container you delete when you exit. Before you exit, run /scan . and read the diff with git diff. If the result is good, recreate the change on a branch in your real checkout under Auto or Ask, and review it like any other change.

The cloud options on the download page give you a similar setup without Docker: the Cloud CLI runs the CLI on Safeguard's infrastructure, and the cloud sandbox is an isolated tenant against a seeded demo repo, free for seven days with no card.

How the modes compare with other coding agents

Most coding agents now have a ladder of approval settings. The names differ, and so do the defaults. The table lists what each tool's own docs say. It maps the closest equivalents, which is an editorial reading, not a claim that the settings behave identically.

A few details from those docs are worth knowing if you move between tools:

• Claude Code has six modes. Its docs say deny rules block in every mode, including bypassPermissions, and that an organisation can block bypassPermissions with permissions.disableBypassPermissionsMode in managed settings.
• Codex combines a sandbox mode with an approval policy. Its docs say network access is off by default and that destructive app or MCP tool calls always require approval when the tool carries a destructive annotation.
• Gemini CLI says YOLO can only be enabled from the command line, and security.disableYoloMode turns it off even if a flag asks for it.
• Cline recommends enabling "Read project files" and leaving edits, commands, browser and MCP off "until you have a specific reason."
• goose applies Autonomous mode by default, so check the mode before the first task.
• Qwen Code cycles plan, default, auto-edit, auto and yolo with Shift+Tab.

Safeguard keeps it to three settings on purpose. Three is few enough that everyone on a team can remember them and say them out loud in a review: "I ran that in Ask."

The same three modes appear outside the terminal. With the Safeguard Chrome extension, Search works in a browser tab you hand it, step by step. You set Ask, Auto or Yolo; it stops and asks before a risky step such as submitting a form, with Allow once or Don't allow; and every step is kept on record. Browser control must be enabled for the workspace.

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

For a wider look at these tools, see our comparison of AI coding agents and our list of Claude Code alternatives.

Team guidance: agreeing on a mode

An approval mode is a personal setting, but the risk it controls is shared. A short written agreement saves arguments later. Here is a template you can adapt.

A simple mode policy

Rules that make the policy work

1. Say the mode in the pull request. One line in the description: "Prepared with the Safeguard CLI in Auto." Reviewers then know how much was seen before it was written.
2. Scan before and after. Run /scan . or safeguard scan --dir . at the start and end of any session that changed dependencies. The difference in vuln.json is what the session did to your risk.
3. Let the platform enforce what matters. Policies and gates are evaluated in the Safeguard platform, not by the CLI. Put the rules you cannot afford to skip there, so they apply whatever mode anyone chose.
4. Keep fix PRs reviewable. The platform's autonomous remediation opens fix PRs, and it is off by default. If you turn it on, those PRs go through the same review as everything else.
5. Downgrade, never upgrade, when surprised. If an Auto prompt surprises you, decline it and switch to Ask. Do not switch to Yolo to make the prompts stop.
6. Use the same words everywhere. The CLI and the browser extension both use Ask, Auto and Yolo. Teach them once.

Common mistakes

• Leaving Yolo on after a demo. The mode belongs to the session. Check the bar under the input when you start real work.
• Treating Auto as Yolo. Auto still asks about anything new. Approving those prompts without reading them turns Auto into Yolo in practice.
• Running Yolo in your home directory. The assistant can reach local files. Point Yolo at a folder you can delete, inside a container or VM.
• Giving CI a write task. A non-interactive run has no one to approve it. Keep safeguard exec prompts to reading and reporting unless you have checked the docs for your version.
• Reading only the diff. A diff shows which lines changed. It does not show whether a new package carries a known vulnerability. Scan.
• Forgetting the mode is per tool. Your Claude Code or Codex setting does not carry over. Our guide to checking what a coding agent changed shows how to scan after any of them.

One platform on every surface

Approvals sit inside a wider setup. Start in the CLI, continue in the desktop app 3.2.2 for Windows, macOS and Linux, where you ask your supply chain anything in plain English in a native window, and check findings on your phone with the iOS app for iPhone and iPad or the Android app for phones and tablets. The IDE extension covers VS Code, JetBrains and Open VSX. The browser extension 1.0.4 installs from the Chrome Web Store for Chrome, Brave, Arc, Vivaldi, Opera and Edge, from Firefox Add-ons, and in Safari on iPhone and iPad inside the iOS app; Safari on Mac is in Apple review. Everything is on the download page.

FAQ

What is the default approval mode in the Safeguard CLI?

Auto. The docs describe it as "Approve known actions, ask for anything new. The default." The current mode is always shown in the bar under the input.

How do I change the approval mode?

Type /permissions in the interactive terminal and choose Ask, Auto or Yolo. You can change it at any point in a session.

Which actions ask for approval?

The docs name writing a file, editing code and running a command as the tools that change things and ask before they act. How often they ask depends on the mode.

Is Yolo mode safe?

It approves everything and never asks, so it is only as safe as the place you run it. Use it in a container, a VM, a throwaway clone or the cloud sandbox, never on a machine with production credentials or a repository you cannot rebuild.

Can I use my Claude or ChatGPT plan, and does the mode change?

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. The approval mode works the same whichever model you pick with /model. You can also connect Claude or ChatGPT to the Safeguard MCP server and use Safeguard from that chat.

Does the browser extension use the same modes?

Yes. In the Chrome extension, you set Ask, Auto or Yolo for Search working in a browser tab. It stops before risky steps such as submitting a form, and every step is kept on record. Browser control must be enabled for the workspace.

What about CI?

Use safeguard exec, which runs one non-interactive assistant turn. Give it prompts that read and report, such as "summarise the critical findings in this repository," and keep code changes in sessions where a person can approve them.

Does my source code leave my machine?

When the local runner runs platform scan jobs, your source code never leaves the machine; only SBOMs and findings are uploaded. Your chosen model provider receives what the assistant sends it.

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.

When you are ready, download Safeguard, run safeguard, type /permissions, and start your first session in Ask. The CLI docs cover the rest, and our post on the Safeguard CLI as an AI assistant on your machine goes further on everyday use.

Quick check

Sources

• Safeguard CLI docs
• Safeguard CLI interactive terminal docs
• Safeguard download page
• Claude Code permission modes, Anthropic docs
• Codex agent approvals and security, OpenAI docs
• OpenAI Codex repository
• Gemini CLI configuration reference
• Gemini CLI repository
• Cline auto approve docs
• Cline repository
• goose permission modes
• goose repository
• Qwen Code approval modes
• Qwen Code repository

Last reviewed: 21 October 2026.