Resume Safeguard CLI sessions and pick up where you left off

To resume a Safeguard CLI session, open the terminal in the same folder you worked in and type /resume. That picks up your last session in that folder, so the assistant continues the same conversation. From the shell, safeguard --continue does the same job, and safeguard --resume=ID reopens one specific session you named earlier.

You do not have to give up the assistant you already pay for to work this way. 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 would rather stay in the chat app you use today, connect Claude or ChatGPT to the Safeguard MCP server and ask about your findings from there.

What you will have at the end

Work through this guide once on a real repository and you will have:

• A habit for ending a session so it is easy to resume: commit or stash first, then /quit.
• Three ways back into work: /resume inside the terminal, safeguard --continue from the shell, and safeguard --resume=ID for a named session.
• Named, pinned sessions per task, so a security fix and a refactor in the same repository never get mixed up.
• A way to branch a session with --fork-session when you want to try a second approach without losing the first.
• A rollback routine with safeguard checkpoints, previewed with --dry-run before anything changes.
• The same live session visible in the desktop app and the phone app, where you can approve the next command.

The examples use payments-api, the sample Node.js project from our recorded demos.

How sessions work in the Safeguard CLI

Run safeguard with no arguments and you get the interactive terminal. Everything you do there belongs to a session. Four facts explain most resume questions.

A session belongs to a folder. The docs describe /resume as resuming "your last session in this folder". Start in ~/code/payments-api yesterday and you need to start there again today. A parent folder or another clone is a different folder.

Resuming brings back the conversation, not a frozen copy of your files. Your files are whatever is on disk when you come back. If you pulled new commits, switched branches or edited files by hand overnight, the assistant sees the new state the next time it reads them. Tell it what changed.

File edits by the assistant are checkpointed. The CLI's help explains that files the agent writes or edits are snapshotted before each change, and safeguard checkpoints lets you list and restore them. Anything a shell command writes is not snapshotted. That includes npm install rewriting package-lock.json. Git is your undo for those.

A signed-in session is live. Once you run /login, a CLI session shows in the web app, the desktop app and the phone app, and those devices can send work to it.

Every way back into a session

All of these come from the CLI's --help output and the slash command docs.

Step by step walkthroughs

1. Stop for the day and resume tomorrow

This is the routine you will use most.

1. Finish or pause the current step. If the assistant is mid-task, press esc. It interrupts whatever is running without exiting, so you can still ask a final question.

2. Ask for a handover note. Type something like:

   summarise where we are: what you changed, what is left, and any command you were about to run
   

   The answer stays in the transcript for when you resume. /copy puts it on your clipboard for a ticket or commit message.

3. Save your files in Git. The session will be there tomorrow, but your working tree is only as safe as Git makes it. Either commit:

   git add -A
   git commit -m "wip: lodash upgrade, tests not yet run"
   

   or stash, which the Git docs describe as saving your local changes as a stash entry and resetting the working tree to HEAD:

   git stash push -m "lodash upgrade in progress"
   

4. Exit the terminal. Type /quit.

5. Next morning, start in the same folder.

   cd ~/code/payments-api
   git stash pop        # only if you stashed
   safeguard
   

6. Resume. Type /resume. The previous conversation comes back, including the handover note from step 2.

7. Re-sync the assistant. Before asking for new work, tell it what changed overnight:

   I pulled main and popped my stash. Re-read package.json and package-lock.json, then continue from your summary.
   

8. Check the approval mode. The current mode is always shown in the bar under the input. Type /status if you want the full picture, which includes user, tenant, runner, job counts and approval mode. If you changed modes yesterday for a one-off task, set it back with /permissions before you continue.

Most resume problems come from skipping step 3 or step 7.

2. Name and resume sessions from the shell

When you run more than one piece of work in the same repository, "the last session in this folder" stops being precise enough. Pin an id when you start, and you can always get back to the right one.

1. Start the session with a pinned id and a name.

   cd ~/code/payments-api
   safeguard --session-id payments-lodash --name "lodash upgrade"
   

   The help text says the id may contain letters, digits, dot, dash and underscore. Pick something you will remember, such as the repository plus the task.

2. Start a second, unrelated session the same way.

   safeguard --session-id payments-logging --name "structured logging refactor"
   

3. Resume the one you want, by id.

   safeguard --resume=payments-lodash
   

4. Or resume the most recent one without typing an id.

   safeguard --continue
   

5. Resume from anywhere. If your shell is somewhere else, point the CLI at the folder with -C:

   safeguard -C ~/code/payments-api --resume=payments-lodash
   

A repo-task pattern, such as payments-lodash, keeps ids unique and easy to type.

If you run a quick throwaway question you never want to come back to, add --private. The help describes it as "do not record this run in the session store", so it will not crowd the list or become the session --continue picks.

3. Fork a session to try a second approach

Sometimes you want to explore an alternative without losing the conversation you have. A common case: the assistant proposed upgrading a dependency to the next major version, and you want to compare that with staying on the current major and applying a patch release.

1. Commit the current state so both approaches start from the same files.

2. Create a separate folder for the experiment with a Git worktree. The Git docs explain that git worktree add creates a linked working tree that shares the repository with your main one:

   git worktree add ../payments-api-major -b try-major-upgrade
   

3. Fork the session into that folder.

   safeguard -C ../payments-api-major --resume=payments-lodash --fork-session
   

   The help describes --fork-session as copying the session into a new one instead of extending it. The original session keeps its history untouched.

4. Ask for the alternative approach in the fork:

   Try the major version upgrade instead. Show me the diff and run the tests before anything else.
   

5. Compare the two folders, keep the branch you prefer, and clean up:

   git worktree remove ../payments-api-major
   

   Git only removes clean worktrees unless you pass --force, which is a useful guard against throwing away work by accident.

Because /resume works per folder, the worktree folder also gets its own "last session". Typing /resume in ../payments-api-major later brings back the fork, not the original.

4. Roll files back with checkpoints

Resuming is about the conversation. Checkpoints are about the files. Use them when you come back and decide the last few edits were a wrong turn.

1. List the checkpoints for the session.

   safeguard checkpoints list --session payments-lodash
   

   They come back oldest first. Add --json if you want to read them with a script.

2. Preview a restore before doing it.

   safeguard checkpoints restore 3f2a --session payments-lodash --dry-run
   

   The help says --dry-run changes nothing and prints what would change, with a diff per file. A checkpoint can be named by a prefix of its id when only one matches.

3. Restore files only, keeping the conversation.

   safeguard checkpoints restore 3f2a --session payments-lodash --files-only
   

   Without --files-only, the transcript is rolled back to the same point as well, which is what /rewind does inside the terminal.

4. Resume and tell the assistant.

   safeguard --resume=payments-lodash
   

   I restored the files to before the major upgrade. Re-read package.json and try the patch release instead.
   

Two details from the help are worth knowing. A restore puts every file changed since the checkpoint back as it was, and removes files the agent created. And the state it overwrites is kept as a new checkpoint, so a restore can itself be undone. What it cannot undo is anything a shell command wrote, so git checkout -- package-lock.json or git stash stays part of your routine.

Carry the same session to the desktop and your phone

A signed-in CLI session is live. It appears in the web app, the desktop app and the phone app, and those devices can send work back to it. You do not need a separate "resume" step on the other devices: the conversation is simply there.

In the recorded Android session below, the same conversations appear on the phone. Choosing "Work on my computer" picks a computer running the CLI and a folder, the command waits on the phone for Allow once, Allow for turn or Deny, and the answer shows the tests passed.

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

The desktop app works the same way. In the recorded desktop session, the CLI session shows in the app's conversation list, and "2 connected" shows the computer, the browser and Safeguard cloud. You ask for work on your computer, pick the computer and folder, then Approve or Deny each command and file edit. Our desktop app guide and the guide to Safeguard on Android phones and tablets cover installation.

A practical pattern for a long upgrade: start in the terminal with a pinned session id, leave the CLI running and signed in when you step away, and approve the next command from the desktop app or phone. Back at the laptop, the terminal shows everything that happened, and if you had quit, safeguard --resume=payments-lodash brings it back.

Two related commands help here. safeguard devices lists your signed-in devices that can send and receive, and safeguard inbox shows what your other devices sent to this CLI, such as links, text, files or conversations. safeguard send --to laptop --text "..." goes the other way.

Long sessions: /compact, /clear or a fresh start

A session you resume for a week accumulates context. Three tools keep it manageable.

• /compact summarises the conversation to free context. Use it when a resumed session has a lot of old back and forth that no longer matters, for example after a long debugging detour.
• /clear clears the conversation and also forgets the context the assistant was carrying. Use it when you want a clean slate in the same terminal.
• A new session is often the right answer for a new task. A fresh --session-id keeps the history of the old task intact and resumable, while the new task starts clean.

Resume when the next step depends on what was said before. Start fresh when it does not.

Do the work properly with the Safeguard CLI

Resuming is most useful when the session is doing real work: writing and fixing code with an assistant that also knows your vulnerabilities. Here is the setup in brief.

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, with Windows on x86_64 only. The download page notes that the installer verifies the checksum. Step by step guides exist for macOS and the other platforms.

First session

Run safeguard, type /login to sign in through the browser, then /scan . to scan the current folder. From there, ask in plain language, for example "how many critical vulns do we have" or "fix the lodash CVE in this repo".

Writing and fixing code

The assistant has tools for your local files and for your Safeguard data, and it can write files, edit code and run commands with your approval. The recorded session below shows the whole loop on the payments-api project: install with the curl command, safeguard --version, then safeguard opens the terminal. Asked to "fix the lodash CVE in this repo", the assistant reads the finding, the files and the advisory, then asks before each command, where you 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. The session ends with /permissions, /model and /scan ..

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

That suggested commit message is a natural point to commit, /quit, and /resume tomorrow.

Using your Claude, ChatGPT or Codex plan

You can bring the plan you already pay for into the CLI, and Safeguard adds no extra charge for that usage. Your provider's own limits and terms still apply. To see or switch the model a session uses, type /model; for connecting a model, see the CLI docs. You can also keep working in the Claude or ChatGPT app and connect Claude to the Safeguard MCP server so it can use Safeguard from the chat.

Approvals

/permissions chooses how often the assistant asks. The modes are Ask (reads run; edits and commands ask first), Accept edits (edits in this folder and read-only commands run; other commands ask), Plan (read and plan only), Auto (read-only commands and what the policy allows run; anything else asks; the default) and Strict (pre-approved actions only, for CI). A --yolo flag approves everything; keep it for throwaway sandboxes only. Plan mode is a good fit for the first few minutes after a resume, while the assistant re-reads the files.

CI with safeguard exec

For pipelines, safeguard exec runs one non-interactive assistant turn and exits:

safeguard exec "summarise the critical findings in this repository"

Its default permission mode is strict, so anything not pre-approved by the policy is denied, and it refuses to run outside a git repository unless you pass --skip-git-repo-check. Policies and gates are evaluated in the platform, not by the CLI. More in running the Safeguard CLI in CI with safeguard exec.

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

Troubleshooting

/resume opens nothing, or the wrong session. Check the folder first. Run pwd and compare it with where you started last time. A different clone, a parent folder or a worktree is a different folder. If you pinned an id, skip the guesswork with safeguard --resume=ID.

The session you want was a private run. Runs started with --private or --no-session-persistence are not written to the session store, so there is nothing to resume. Start a new session and paste in what you need.

--continue picked a different session than you expected. It continues the most recent session in the workspace. If you ran a quick question after your main task, that question is now the most recent. Use a pinned id for the main task, or --private for quick questions.

A restore did not bring back package-lock.json. Checkpoints cover files the agent wrote or edited, not files a shell command wrote. Use Git: git checkout -- package-lock.json or git stash.

The session does not appear on the desktop or phone. Type /whoami in the terminal to confirm you are signed in, and /login if not. safeguard doctor checks environment, sign-in, tools and policy and changes nothing. Read its lines rather than its exit code, which is 0 whenever the checks ran.

Common mistakes

• Starting in the wrong folder. The most common reason /resume "loses" a session. Make cd into the project root the first thing you do.
• Relying on the session as your backup. The session holds the conversation. Git holds your files. Commit or stash before you stop.
• Resuming without re-syncing. If anything changed on disk, tell the assistant before it acts on yesterday's picture.
• One giant session for everything. Mixing tasks makes /resume less useful and the context noisier. One session per task, with a pinned id.
• Restoring without a preview. Always run checkpoints restore with --dry-run first.
• Leaving a permissive mode on. Switch back from Accept edits before you resume work that runs install commands.
• Using --yolo on a real machine. It approves everything. Keep it for throwaway sandboxes.

FAQ

How do I resume my last Safeguard CLI session?

Open a terminal in the same folder, run safeguard, and type /resume. Or run safeguard --continue from the shell to open straight into the most recent session in that workspace.

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 use Safeguard from the chat you already use.

How do I resume a specific session rather than the last one?

Pin an id when you start with safeguard --session-id payments-lodash, then resume it with safeguard --resume=payments-lodash. Add -C with a path if your shell is in another folder.

Does resuming undo or redo any file changes?

No. Resuming brings back the conversation. Your files stay as they are on disk. To roll files back, use safeguard checkpoints restore with --dry-run first, and Git for anything a shell command wrote.

Can I try a different approach without losing the original session?

Yes. Add --fork-session to --resume or --continue. The CLI copies the session into a new one, and the original stays as it was. Pair it with a Git worktree so the files are separate too.

Can I continue a CLI session from my phone or the desktop app?

A signed-in CLI session is live and shows in the web, desktop and phone apps. From the desktop or phone app you can send work to a computer running the CLI, pick the folder, and approve each command and file edit.

What happens to my source code during a session?

The assistant works on files on your machine, and edits and commands ask first according to your approval mode. When the local runner runs platform scan jobs, source code stays on the machine and only SBOMs and findings are uploaded.

When should I start a new session instead of resuming?

When the next task does not depend on the previous conversation. Use /compact to trim a long session you still need, /clear for a clean slate in the same terminal, and a new pinned id for a new task.

Try it yourself

If you have not set up the CLI yet, this demo shows 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.

Download the CLI, desktop and mobile apps from safeguard.sh/download, and keep the CLI docs open while you work through the walkthroughs above.

Quick check

Sources

• Safeguard CLI documentation
• Safeguard CLI: Interactive terminal
• Safeguard CLI: Slash commands
• Safeguard CLI: Usage guide
• Safeguard downloads
• Git documentation: git-worktree
• Git documentation: git-stash

Last reviewed: 21 October 2026.