You can send work from the Safeguard desktop app to any computer where the Safeguard CLI is running and signed in. Ask for the job in a conversation, pick the computer and the folder, then Approve or Deny each command and file edit as it comes up. The work happens on that computer, in that folder.
You also keep 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. And if you live in the Claude or ChatGPT apps, connect either one to the Safeguard MCP server and use Safeguard from the chat you already have open.
Facts here come from the Safeguard download page and docs as checked on 21 October 2026, and from sessions we recorded that day with CLI 11.11.0, desktop app 3.2.2 and the Android app 2.0.3.
What you will have at the end
By the end of this guide you will have:
- The Safeguard CLI installed, verified and signed in on the computer that holds your code.
- That computer kept reachable, either through an open CLI session or a headless runner that starts when you log in.
- The desktop app installed and showing the same conversations as your terminal.
- A finished task sent from the desktop app: a dependency upgraded, the tests run, and every command and edit approved by you.
- A permission mode chosen on purpose, a way to undo edits, and fixes for common problems.
How sending work to your computer works
Three things take part, and it helps to know which one does what.
| Piece | Where it runs | What it does in this workflow |
|---|---|---|
| Safeguard CLI | The computer with your code (macOS, Linux or Windows) | Reads files, edits code and runs commands in the folder you pick, after you approve |
| Desktop app 3.2.2 | Your Windows, macOS or Linux desktop | Where you ask, pick the computer and folder, and press Approve or Deny |
| Safeguard platform | Safeguard cloud | Carries the conversation and your findings between devices |
The CLI is the part that touches files. The desktop app only asks and approves, so it does not need your source on its own disk.
A CLI session is live. When you run safeguard in a terminal, that session shows in the web app, the desktop app and the phone app, and other devices can send work to it. The runner docs say all traffic is outbound HTTPS opened by the runner, and nothing connects to it. So you do not open a firewall port or forward anything.
The approvals happen where you are. When the desktop app sends a task, each command and file edit waits in the desktop app for you to Approve or Deny.
Before you start: install, verify and sign in
Do this once per computer that should take work.
1. Install the CLI
The CLI is one static binary with no Node, Python or JVM to install. 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
Each release publishes a SHA256SUMS file, and the download page says the installer verifies it before putting anything on your PATH. Our macOS install guide goes step by step.
2. Check it
safeguard --version
safeguard doctor
safeguard doctor checks the environment, sign in, profile, policy and tools, and prints what is wrong in the order that matters. It changes nothing. Its exit code is 0 whenever the checks ran, so read the lines rather than the status.
3. Sign in
Run safeguard with no arguments to open the interactive terminal, then type /login. Your browser opens, you approve the session, and the terminal picks it up. /whoami shows who you are signed in as. Sign in with the same account you will use in the desktop app; work can only be sent between devices signed in to the same account.
4. Install the desktop app
Get version 3.2.2 from https://safeguard.sh/download:
- Windows 10 and 11: one installer for x64 and ARM, per user, no admin rights. It is not yet code-signed, so SmartScreen may warn: check the SHA-256 first, then More info, then Run anyway.
- macOS 12 and later: Apple Silicon build, signed and notarized; an Intel build is linked.
- Linux: an x86_64 AppImage that needs the CLI on your PATH, so do steps 1 to 3 first.
Our desktop app guide covers each installer in detail.
Keep the computer reachable
The desktop app can only send work to a computer whose CLI is running. You have three ways to keep it running, and they suit different days.
| Option | Command | Runs while | Good for |
|---|---|---|---|
| Interactive session | safeguard | The terminal window is open | Working at the machine, with the desktop app as a second screen |
| Headless runner | safeguard runner start --workspace ~/code/payments-api | That process is running | A workstation you leave on for the afternoon |
| Login service | safeguard runner install --workspace ~/code/payments-api | You are logged in, from login onward | A machine you want reachable every day without thinking about it |
The interactive session
Open a terminal in your project and run safeguard. The session is live on your other devices while the window stays open. /logout signs out and takes the runner offline.
The headless runner
safeguard runner start runs without the terminal interface. Its help says it polls the platform for turns in conversations pinned to it, validates each selected workspace and relays every step back. --workspace sets the default folder.
cd ~/code/payments-api
safeguard runner start --workspace .
In another terminal, check on it and stop it when you are done:
safeguard runner status
safeguard runner stop --workspace ~/code/payments-api
runner stop drains work in flight before stopping. Only one headless machine runner may run per user account; interactive sessions stay independent of it.
The login service
safeguard runner install registers runner start as a per user login service so your phone or browser can send work to the machine from any network for as long as it is on. Sign in with safeguard login first. The service type depends on the system:
- macOS: a LaunchAgent. Apple's launchd documentation says a user agent is specific to a logged in user and runs only while that user is logged in.
- Linux: a systemd user unit. If you want a headless Linux box to run user services without an active login, systemd's
loginctl enable-lingeris the documented way to keep a user manager running after logout. - Windows: a logon scheduled task. Microsoft's Task Scheduler docs list "when a user logs on" as one of its triggers.
safeguard login
safeguard runner install --workspace ~/code/payments-api
safeguard runner status --json
runner status --json prints the running process, the runner identity and whether the service is installed. To remove it, run safeguard runner uninstall.
Send your first task from the desktop app
This walkthrough follows the session we recorded on 21 October 2026. The sample project was payments-api, a small Node.js service with test data, and the job was to fix a vulnerable lodash version.
- Open the desktop app and sign in with the same account as the CLI.
- Find your CLI session in the conversation list. In the recording, the session started in the terminal appeared in the desktop app's list without any extra step. Open it if you want to continue that thread, or start a new conversation.
- Check what is connected. In the recording, "2 connected" covers the computer running the CLI, the browser under Safeguard control with its Ask, Auto or Yolo setting, and Safeguard cloud. If your computer is not there, go back to the previous section; the CLI is not running or is signed in to a different account.
- Ask for work on your computer. Type the request in plain language, for example: "On my computer, upgrade lodash in payments-api to a fixed version and run the tests."
- Pick the computer. The app asks which computer to use. Choose the one running the CLI.
- Pick the folder. The picker offers your computer, a recent folder, or Browse. Browse to
payments-apiand click Open here. The runner checks that the folder is a valid workspace before it starts. - Approve or Deny each step. Each command waits for you and shows exactly what will run; Approve runs it once and Deny stops it. The edit to
package.jsonwaits too, and its card names the file it touches. Before the test run, the change is listed under File changes so you can see what moved so far. - Read the result. The session ended with lodash upgraded, the lockfile matching and
npm testpassing. It also pointed out other dependencies worth a look, which makes a good next request.
Know the two npm commands before you approve them. npm's docs say npm install installs the dependencies in package.json and updates package-lock.json too, and npm test runs whatever the test property of the scripts object defines. So approving npm test means approving that project's own test script.
Here is the recorded desktop session. Click through it to see the conversation list, the folder picker and each Approve or Deny prompt.
Click through it at your own pace, or open it full screen.
Check the result yourself
The assistant reports what it did, but check for yourself, on the machine or in a follow-up request:
git status
git diff HEAD -- package.json package-lock.json
npm test
Git's docs describe git diff HEAD as the changes in your working tree since your last commit, which is exactly what the task changed. The CLI session in our recording ended with a suggested commit message and pushed nothing, so committing and pushing stays your decision.
Requests that work well
The assistant has tools for local files and for your Safeguard data, and picks whichever the question needs. Good requests name the outcome, the scope and the check.
Fix a known finding. "Fix the lodash CVE in this repo," the example from the CLI docs. The assistant reads the finding, the files and the advisory, then asks before each change.
Scan before you trust a change. "Scan this folder and tell me about anything critical." This builds an SBOM, matches it against vulnerability databases and writes JSON results such as vuln.json under ./output:
safeguard scan --dir .
Check findings without uploading anything. "List the dependency findings locally, nothing uploaded." Per its help, this uploads no project, finding or file even when the CLI is signed in:
safeguard findings sca --dir .
Review uncommitted work. "Review my working tree changes for correctness and security." That maps to:
safeguard review
safeguard review --base main
--base diffs against a git ref instead of the working tree. If an AI coding agent wrote the change, our guide to reviewing AI generated code before merge goes further.
Preview a dependency fix. "Show me what a fix for high and critical findings would change, but do not apply it." That is a dry run:
safeguard fix --dry-run --severity high
Plain file work. "What's the latest file in ~/Downloads" is another docs example. With your approval it finds and reads files, edits code and runs commands that have nothing to do with security.
Two habits help: say what done means ("and run the tests", "stop before installing anything"), and keep one job per request so each approval is easy to judge.
What to approve, and how much to allow
Every command and file edit sent from the desktop app waits for you. That is a feature, so use it well:
- Read the command, not the summary. Approve
npm test; think twice about anything withrm,curl ... | sh, or a path outside the folder you picked. - Read the edit. A version bump in
package.jsonshould touch one line. If it touches twenty, Deny and ask why. - Deny freely. Deny stops that step. You can then say what you want instead in the same conversation.
Permission modes
In the interactive CLI, /permissions sets how much runs without asking. The modes in CLI 11.11.0 are:
| Mode | What runs without asking | What asks first |
|---|---|---|
| Ask | Reads | Edits and commands |
| Accept edits | Edits in this folder and read only commands | Other commands |
| Plan | Reading and planning only | Nothing is changed |
| Auto (default) | Read only commands and what the policy allows | Anything else |
| Strict | Pre-approved actions only, for CI | Everything else is refused |
There is also a --yolo flag that approves everything. Keep it for throwaway sandboxes only, never for a machine that other devices can send work to.
The headless runner and the login service take the mode as a flag, -a or --permission-mode, with the values supervised, edits, plan, guarded, strict and autonomous. Set it on purpose for a machine left on all day.
Undoing file edits
Files the assistant writes or edits are snapshotted before each change. /rewind in the interactive terminal and the safeguard checkpoints command use the same checkpoints:
safeguard checkpoints list --session <id>
safeguard checkpoints restore <checkpoint> --session <id> --dry-run
safeguard checkpoints restore <checkpoint> --session <id> --files-only
--dry-run shows what would change as a diff. A restore is itself kept as a new checkpoint, so you can undo the undo. One caution from the help text: anything a shell command writes is not snapshotted. In the npm example, the edit to package.json is covered, but the package-lock.json changes and node_modules written by npm install are not. That is why we work in git and check git status afterwards.
Continue on your phone
The same flow works from the phone. In the Android app, the same conversations appear; "Work on my computer" picks a computer running the CLI and a folder; each command waits for Allow once, Allow for turn or Deny; and the answer shows when the tests pass. Allow for turn is the phone's way to say yes to the rest of that turn, so use it only once you trust the plan.
Click through it at your own pace, or open it full screen.
Android installs from Google Play, or as a direct APK for phones without it; iPhone and iPad install from the App Store. Our Android guide has the details.
Do the work properly with the Safeguard CLI
Everything above depends on the CLI, so it is worth knowing what it does on its own. 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.
Install
curl -fsSL https://cli.safeguard.sh/install | bash on macOS and Linux, irm https://cli.safeguard.sh/install.ps1 | iex on Windows. Single static binary; macOS, Linux and Windows; x86_64 or arm64, with Windows on x86_64 only. safeguard self-update updates the binary later. Its help says it verifies a signed release manifest, checks the archive digest, runs the new binary to prove it works and only then swaps it in, keeping the old one as safeguard.previous. safeguard self-update --check reports a new version without installing it.
First session
Run safeguard with no arguments. /login signs in through the browser, /scan . scans the current folder, and you can then ask in plain language, for example "fix the lodash CVE in this repo" or "how many critical vulns do we have." Type @ to attach a file from the folder you started in, /copy puts the last answer on your clipboard, and /resume picks up your last session in that folder. Outside the interactive terminal, safeguard scan also takes --repo, --image or --sbom, and safeguard validate checks CycloneDX, SPDX and VEX documents.
Writing and fixing code
The assistant has tools for local files and for your Safeguard data. With your approval it writes files, edits code and runs commands. Because it also knows your vulnerabilities, a request like "upgrade this dependency" is grounded in what is actually flagged for that project. When another agent did the writing, scan the folder with the CLI before you merge.
Using your Claude, ChatGPT or Codex plan
This is where the plan you already have comes in. Your Claude, ChatGPT or Codex plan works inside the CLI with no extra Safeguard charge for that usage, and your plan's own limits and terms still apply. /model shows or switches the AI model; with no argument it opens a picker, and with a name it switches directly. For connecting a model, see the CLI docs or /model.
Approvals
Tools that change things ask before they act, under the mode you set with /permissions: Ask, Accept edits, Plan, Auto (the default) or Strict. The desktop and phone apps show the same approval requests when they send the work.
CI with safeguard exec
safeguard exec "summarise the critical findings in this repository"
safeguard exec runs one assistant turn with no prompts. Its default mode is strict: nothing is asked, and anything the policy file has not pre-approved is denied. It refuses to run outside a git repository, because there would be no way to undo what it changes. Our CI guide for safeguard exec covers pipelines. Policies and gates are evaluated in the platform, not by the CLI, and when the local runner runs platform scan jobs, your source never leaves the machine; only SBOMs and findings are uploaded.
Troubleshooting
The computer does not appear in the desktop app. Check that the CLI is running there (safeguard runner status) and signed in to the same account (/whoami in the terminal). Then run safeguard doctor and read the first problem it lists.
The folder is missing from the picker. The runner help says its browsing starts from your home folder and fixed drives, and a user setting, runner.browse_roots, adds more roots. Folders elsewhere need that setting.
Requests hang on a corporate network. By default the runner long polls, and the server may hold each poll for up to 25 seconds. Some networks forbid held connections. Start it with interval polling instead:
SAFEGUARD_POLL_INTERVAL=10 safeguard runner start --workspace . --poll-wait 0
The runner stops right after it starts. If it cannot read your tenant's runner policy it fails closed by design. Ask your Safeguard admin to check the policy.
A second runner will not start. Only one headless machine runner may run per user account. Stop the first with safeguard runner stop, or keep it and use an interactive session alongside.
Common mistakes
- Two accounts. The CLI signed in to a personal account and the desktop app to the work one. They will never see each other.
- Closing the terminal and expecting the computer to stay reachable. Use
runner startorrunner installfor that. - Using
--yoloon a shared machine. It approves everything, including work sent from another device. Sandboxes only. - Picking the parent folder. Choose the project folder itself, so commands like
npm testrun where the project'spackage.jsonlives. - Forgetting the login service. It keeps the machine reachable every day. Remove it with
safeguard runner uninstallwhen you no longer want that.
FAQ
Does my code leave my computer when I send work from the desktop app?
The files stay on that computer; the CLI reads and edits them there, and the runner only opens outbound HTTPS. What the assistant reads to answer you is part of the conversation with the model you chose. For platform scan jobs, only SBOMs and findings are uploaded, never source.
Can the desktop app and the CLI be on different computers?
Yes. The desktop app asks and approves; the CLI must run on the computer that holds the code, signed in to the same account.
Do I need to keep a terminal open?
No. Use safeguard runner start, or safeguard runner install to start the runner at login.
Can I keep my Claude, ChatGPT or Codex plan?
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 use Safeguard from those apps.
What happens if I press Deny?
That step does not run. Say what you want instead in the same conversation.
Can I approve from my phone instead?
Yes. The Android app shows the same conversations, and "Work on my computer" sends a task to a computer running the CLI. Each command waits for Allow once, Allow for turn or Deny.
Which permission mode should a machine that takes remote work use?
Start with the default, Auto, or with Ask if the repository is sensitive. Never use --yolo on a machine other devices can send work to.
How do I undo an edit the assistant made?
Use /rewind in the terminal or safeguard checkpoints restore, with --dry-run first. Shell command output is not snapshotted, so use git for that.
Try it yourself
This demo covers the setup that makes a computer reachable: set 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.
Get the CLI, the desktop app and the phone apps from https://safeguard.sh/download, and keep https://docs.safeguard.sh/docs/cli open for the commands.
Quick check
What must be running on a computer before the desktop app can send work to it?
The Safeguard CLI, signed in to the same account: either an open safeguard session, safeguard runner start, or the login service from safeguard runner install.
Which changes do checkpoints not cover?
Anything a shell command writes, such as the lockfile and node_modules written by npm install. Checkpoints cover the files the assistant writes or edits.
What does the runner do on a network that forbids held connections?
Start it with --poll-wait 0, which polls at a fixed interval set by SAFEGUARD_POLL_INTERVAL, 10 seconds by default.
Sources
- Safeguard downloads
- Safeguard CLI overview
- Safeguard CLI interactive terminal
- Safeguard CLI slash commands
- Safeguard local runner
- Safeguard desktop application
- npm install
- npm test
- git diff
- Apple: Creating launchd jobs
- systemd loginctl
- Microsoft Task Scheduler
Last reviewed: 21 October 2026.
