Safeguard Cloud CLI Guide: Use Safeguard With Nothing to Install

The Safeguard Cloud CLI is the Safeguard CLI running on Safeguard's infrastructure, so scans need no local runner and there is nothing to install. Start it from Search in the web app under Compute, use it for questions, research and platform scans, and move to the local CLI when work must happen on your own checkout.

Safeguard is one platform on every surface: the terminal, the desktop, the phone, the browser and the cloud. Switching to it does not mean giving up the AI you already pay for. 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.

What you will have at the end of this guide:

1. A clear rule for when to use the Cloud CLI, a cloud sandbox, a cloud browser, a cloud computer or the local CLI.
2. A cloud session started from Search, with the right compute picked for the task.
3. A short daily routine you can run from any browser, including a locked down laptop.
4. A CI step that scans each commit on the Safeguard platform and fails the build on high severity findings.
5. The local CLI installed for the moments when the fix has to happen on your machine, with your approval.

What the Cloud CLI is and when to use it

The download page lists cloud options with nothing to install, all hosted by Safeguard. They sit next to the installed apps, so it helps to see them side by side. Everything in this table comes from the download page and the Safeguard docs, read on 21 October 2026.

A simple rule for choosing

Ask one question: does the work need your files?

• No, it needs answers. "How many critical vulns do we have?", "Which projects are affected?", "What does this advisory mean for us?" Use Search in the web app, the cloud options or the Cloud CLI. Nothing needs to run on your laptop.
• It needs a repository the platform already has. Scanning a project that is imported into Safeguard, or a commit in CI, can run on the platform. The Cloud CLI and platform scans fit here.
• Yes, it needs your checkout. Upgrading a dependency, editing code, running npm test, or scanning code you have not pushed. Use the local CLI. Its runner keeps source on the machine and uploads only SBOMs and findings.

Good reasons to start in the cloud

• You are on a machine where you cannot install software, such as a managed laptop or a shared workstation.
• You are evaluating Safeguard and want to try it on a seeded demo repo before connecting anything real.
• You want a quick answer from your phone or a borrowed browser, and the work does not touch files.
• You want scans that do not depend on any one person's machine being switched on.

When the local CLI is the right call

The local runner is the option the docs describe for private repositories you cannot give a cloud service access to, restricted networks that allow only outbound HTTPS, and fixes to code you have not pushed yet. If your rule is that source code never leaves the machine, use the local CLI for that work.

Start a cloud session, step by step

There are two starting points, depending on whether you already have an account.

If you are new: the cloud sandbox

1. Go to safeguard.sh/download and choose the cloud sandbox under the cloud options.
2. Sign up. The download page describes the sandbox as an isolated tenant against a seeded demo repo, free for seven days with no card.
3. Open Search and ask your first question about the demo repo, for example "how many critical vulns do we have".

Everything you learn in the sandbox carries over. The menus are the same ones you will use on your own projects.

If you already have an account: compute in Search

These labels are from the web app as of 21 October 2026.

1. Sign in at app.safeguard.sh and open Search.
2. Click the + button at the bottom left of the message box. Under Tools, open Compute. With nothing running it says "No machine".
3. Open Sandboxes. Under "Run this search in" you will see three choices:
   • No sandbox: Safeguard cloud answers directly. Nothing runs on a machine.
   • A new sandbox: each search gets its own isolated cloud sandbox, and only allowlisted commands run in it.
   • Start new: start a sandbox, cloud computer, CLI or browser.
4. Pick Start new, which offers a sandbox, cloud computer, CLI or browser. Choose the CLI for a Cloud CLI, or one of the others if the task needs it.
5. Type your request in the message box and send it.
6. To see what this search can use, click the Computers and browsers button next to the model picker. It lists computers running the Safeguard CLI, your connected browser and the Safeguard cloud, with a note that you change the cloud setting from + and Compute.

The Computers and browsers list is where the cloud, your browser and your own computers meet. This recorded desktop session shows it at "2 connected" with the computer, the browser and Safeguard cloud. The CLI session shows in the desktop app's conversation list, you ask for work on your computer, it asks which computer and folder, you pick the folder, then Approve or Deny each command and file edit. It ends with the upgrade done and tests passing.

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

Keys and tokens for cloud runners

Cloud work sometimes needs credentials, such as a token for a private registry. The download page lists a cloud credential vault that manages the API keys, tokens and secrets cloud runners use, found in the web app under Settings, Developer. Put them there rather than pasting them into a chat message.

Daily workflows in the cloud

Here is how the cloud options fit into a normal week. Each workflow says what runs where.

Workflow 1: morning triage from any browser

Runs in: Safeguard cloud, with No sandbox selected. Nothing runs on a machine.

1. Open Search on whatever device you have.
2. Ask: "How many critical vulns do we have, and how many are new since yesterday?"
3. Ask: "Which projects are affected, and which findings have a fixed version available?"
4. Ask: "Draft a short summary for the team channel with the top three fixes for today."
5. Copy the summary, check it, and post it yourself.

The conversation is saved, so you can pick it up later in the desktop app or on your phone. Our Android guide covers the phone side.

Workflow 2: research a new advisory

Runs in: Safeguard cloud. The cloud entry in the Computers and browsers list is labelled for answers, web search and research.

1. Under +, in the Mode section, turn on Web Search or Research for this search.
2. Paste the advisory link and ask: "Does this affect any version we ship? List the projects and the version each one uses."
3. Ask for a remediation plan: "For each affected project, what is the smallest upgrade that clears it?"

You now know what needs fixing without touching a single file.

Workflow 3: allowlisted commands in an isolated sandbox

Runs in: a new cloud sandbox for each search, with allowlisted commands only.

Pick A new sandbox under Compute when a question needs something run rather than only looked up, and you want that to happen away from your own machine. Because only allowlisted commands run there, this is not a place for arbitrary scripts. If a request needs a command that is not allowed, move the task to the local CLI where you approve each command yourself.

Workflow 4: scan every commit on the platform from CI

Runs in: the Safeguard platform. Your CI job only starts the scan and waits for it.

The CLI's ci scan command has two modes. By default it starts a scan of the project's repository on the Safeguard platform (SAST, SBOM and the rest) and records it as a version named after the branch and commit. A repository not imported yet is imported on its first run, under your connected GitHub, GitLab, Bitbucket or Azure DevOps integration. With --local, the scan runs on the CI runner instead and uploads only the results, never the source; it covers dependencies (SBOM and vulnerabilities), and SAST runs only in platform mode.

Authenticate with a secret key from Settings, Secret Keys in the web app, with the scans:trigger scope (and scans:read for --wait), stored as the CI secret SAFEGUARD_API_KEY. In GitHub, add it under the repository's Settings, Secrets and variables, Actions, then reference it in the workflow:

jobs:
  safeguard:
    runs-on: ubuntu-latest
    steps:
      - name: Install the Safeguard CLI
        run: curl -fsSL https://cli.safeguard.sh/install | bash
      - name: Scan this commit on the Safeguard platform
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
        run: safeguard ci scan --wait --fail-on high

--wait polls until the scan finishes and exits non-zero if it failed or timed out. --fail-on high fails the step when the scan has a vulnerability at high severity or above. To fail on your release policies instead, use --fail-on-gate Release; policies and gates are evaluated in the platform, not in the CLI. If the install step does not put safeguard on the runner's path, check the installation notes in the CLI docs.

Workflow 5: hand the fix to your own computer

Runs in: your machine, through the local CLI.

When triage says "upgrade lodash in payments-api and run the tests", the cloud has done its part. From Search, the desktop app or the phone, pick a computer running the CLI and a folder, and approve each command and file edit there. That is the hand-off the next section sets up.

Do the work properly with the Safeguard CLI

The Cloud CLI is the fastest way to start. The local Safeguard CLI is where the real fix happens. 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.

Install

One static binary, no Node, Python or JVM. It runs on macOS, Linux and Windows, on x86_64 or arm64 (Windows is x86_64 only).

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# Windows (PowerShell)
irm https://cli.safeguard.sh/install.ps1 | iex

safeguard --version

The installer detects your OS and verifies the checksum. On Windows, our Windows install guide covers PowerShell details. Later, safeguard self-update updates the binary, and safeguard update refreshes the vulnerability databases.

First session

1. cd into your project and run safeguard. The interactive terminal opens.
2. Type /login and approve the session in your browser.
3. Type /scan . to scan the folder.
4. Ask in plain language: "fix the lodash CVE in this repo".

The assistant has tools for your local files and for your Safeguard data and picks whichever the question needs. You can use it as a general terminal assistant too: find and read files, edit code and run commands, with your approval. @ attaches a file from the folder you started in, and /resume picks up your last session in that folder.

Writing and fixing code

This recorded session shows a full fix on a Mac. It installs with the curl command (checksum verified), checks safeguard --version, and safeguard opens the interactive terminal. You ask "fix the lodash CVE in this repo". The assistant reads the finding, files and advisory, then asks before each command (press y or n). It edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and prints a summary with a suggested commit message. It pushes nothing. Then it shows /permissions, /model and /scan ..

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

If an edit goes wrong, safeguard checkpoints lists a session's file checkpoints, previews a restore with --dry-run and restores one. These are the same checkpoints /rewind uses. Files the assistant writes or edits are snapshotted before each change; anything a shell command writes is not.

Use the plan you already pay for

As covered at the top, your existing Claude, ChatGPT or Codex plan can run inside the CLI at no extra charge from Safeguard. To connect a model, see /model and the CLI docs. If you are moving over from Claude Code or Codex, safeguard import converts that setup into Safeguard configuration, and safeguard other-agents reads Claude Code, Codex and OpenCode configuration too.

Approvals

Tools that write files, edit code or run commands ask before they act. /permissions in the interactive CLI offers:

A --yolo flag approves everything. Keep it for throwaway sandboxes only.

Scan what changed, then CI

Before you merge anything an agent changed, scan it:

safeguard scan --dir .                  # SBOM + vulnerability match, JSON under ./output
safeguard review                        # review working-tree changes
safeguard findings sca --dir .          # run a scanner locally, nothing uploaded
safeguard ci scan --local --wait --fail-on high   # the CI step, scanning on the runner

safeguard exec "summarise the critical findings in this repository" runs one non-interactive assistant turn for CI, in strict mode by default. See our post on safeguard exec in CI for pipeline examples.

A CLI session is live. It shows in the web app, the desktop app and the phone app, and other devices can send work to it. That is how the cloud and your machine join up: triage in the cloud, fix locally, approve from wherever you are.

Troubleshooting

safeguard doctor checks environment, sign-in and tools and changes nothing, so it is safe to run whenever a local machine misbehaves.

Common mistakes

1. Using the cloud for work that needs your files. If the task is "edit, install, test", run it on your checkout with the local CLI.
2. Pasting tokens into a chat. Use the cloud credential vault under Settings, Developer for anything cloud runners need.
3. Expecting arbitrary commands in a sandbox. Only allowlisted commands run. That is the point of the sandbox.
4. Mixing up ci scan modes. Platform mode scans on Safeguard and includes SAST. --local scans on the runner and uploads only results. Pick on purpose.
5. Judging Safeguard on the sandbox alone. It holds a seeded demo repo. Connect a real project before you decide what your numbers look like.
6. Leaving --yolo on. It approves everything. Use it only in throwaway sandboxes.
7. Assuming policies run in the CLI. Policies and gates are evaluated in the platform; the CLI reports the result.

FAQ

What is the Safeguard Cloud CLI?

It is the Safeguard CLI running on Safeguard's infrastructure, so scans need no local runner. You start it from Search in the web app under +, Compute, with nothing to install.

Do I need to install anything to use the cloud options?

No. The Cloud CLI, cloud sandbox, cloud browser and cloud computer all run in Safeguard's infrastructure and open in your browser. Install the local CLI only when you want to work on files on your own machine.

Is the cloud sandbox free?

The download page describes it as an isolated tenant against a seeded demo repo, free for seven days with no card.

Can I keep using my Claude, ChatGPT or Codex subscription?

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. You can also connect Claude or ChatGPT to the Safeguard MCP server and ask about your findings from the chat you already use.

Does my source code go to the cloud?

That depends on what you run where. Platform scans and the Cloud CLI work on Safeguard's infrastructure. With the local CLI and its runner, source stays on your machine and only SBOMs and findings are uploaded. ci scan --local likewise uploads only results.

What is the difference between a cloud sandbox and the cloud sandbox trial?

Under Compute, a sandbox is an isolated machine for one search that runs allowlisted commands only. The cloud sandbox on the download page is a whole trial tenant with a seeded demo repo, free for seven days.

Can I move a cloud conversation to my own computer?

Yes. Conversations are shared across the web, desktop and phone apps. From any of them you can pick a computer running the CLI and a folder, then approve each command and file edit on that machine.

Which permission modes apply in the local CLI?

Ask, Accept edits, Plan, Auto (the default) and Strict, set with /permissions. A --yolo flag approves everything and belongs in throwaway sandboxes only.

Try it yourself

The cloud needs no runner. When you are ready to bring the work to your own machine, this demo sets up the runner: 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.

Start in the cloud, continue on the desktop and check findings on your phone. Everything is at safeguard.sh/download, and the CLI docs cover every command used here.

Quick check

Sources

• Safeguard download page
• Safeguard CLI documentation
• Safeguard CLI interactive terminal
• Safeguard CLI slash commands
• Safeguard local runner docs
• GitHub Docs: using secrets in GitHub Actions

Last reviewed: 21 October 2026.