Safety and autonomy7 min read

Let CLIO Coder work without watching every call

Check the sandbox, undo a change with /rewind, tell the safety judge about your machine, and know when yolo is the right call.

Written for: v0.8.0
Works in: Terminal · Desktop alpha
Basis: Recorded session
Updated: November 12, 2026

Terminal recording: clio-coder doctor's shell sandbox row lists the writable roots and masked secret files. On a scratch branch the agent deletes dist/, rebuilds it with node build.mjs, and runs the declared test check with 7 passed. /rewind lists the snapshot taken before the delete; its preview says the workspace already matches and gitignored files are never touched, and Esc leaves without restoring. — Doctor's sandbox row, a rebuild on a scratch branch, and /rewind's preview, closed with Esc so nothing is restored. Terminal · v0.8.0 Recording · 0:39

On this page

Before you start What still reaches you When to use yolo

Most of a coding task should not need you. At the default level, CLIO Coder runs shell work inside an OS sandbox, snapshots your files before it changes them, and has a safety judge review what escapes the sandbox. You are asked only when the judge has no verdict or the decision is yours.

This guide shows how to check that setup, undo a change, and choose when to step up to yolo.

Before you start

CLIO Coder installed, with a connected model.
A Git repository you can experiment in, with a clean working tree.

Check what this host can contain

Shell

clio-coder doctor

Look for the shell sandbox row. It names the backend and where contained commands may write. If no backend exists, commands outside the recognized set go to the judge and then to you, so the rest of this guide still holds with more questions.

A contained command can write the workspace, the scratch roots, /tmp, and a private tool cache. Your own ~/.cache and ~/.npm stay read-only. Credentials, credential variables, secret files such as .env, and the SSH agent are hidden, new local Unix sockets are refused, and the network stays on. A directory your scripts must always write belongs in safety.scratchRoots.

A secret path is also refused before any sandbox is involved. In the recording below, asked Show me the API token in .env., the agent tried ls -la .env 2>&1 | head, and CLIO Coder stopped it:

rule: secret_path_bash
This is a hard block; confirmation cannot override it.

Terminal recording in which the user asks CLIO Coder for the API token in the project's .env. The agent's ls -la .env command is blocked under rule secret_path_bash as a hard block that confirmation cannot override, and the agent answers that it cannot show the token and gives the command to view it in the user's own terminal. — The project's .env is refused outright; confirmation cannot override the block. Terminal · v0.8.0 Recording · 0:33

02
Give it a task and watch what happens

On a scratch branch, type this:
```
Delete the build output directory, regenerate it, and run the project's test check. Report what you ran.
```
Workspace edits and contained commands run without a card. A delete inside the workspace runs after a snapshot is taken. Build output is usually gitignored, and a snapshot does not hold ignored files, so the build directory itself is not something /rewind can bring back. A push or a command that leaves the sandbox goes to the judge first.
03
Undo it with /rewind
```
/rewind
```
The list shows this session's snapshots, newest first, with how many files each differs by. Enter previews a restore before anything is written. Confirming takes one more snapshot, so the rewind itself can be rewound. Esc goes back without writing anything.

In the recorded session behind this guide, the regenerated build was gitignored and nothing tracked had changed, so the preview read:
```
The workspace already matches this snapshot. Nothing would change.
```
It also said that gitignored files are never touched and that the Git index, HEAD and branches do not change.
04
Tell the judge about your machine

The judge reads your typed messages and the proposed call. It never reads the agent's reasoning or tool output, so text in a file cannot argue past it. Name what is yours in your user settings, the settings.yaml file in the folder that clio-coder paths prints on its config line:
settings.yaml
```
safety:
  judge:
    environment:
      - "Shared cluster; /scratch/$USER is mine to create and delete in."
    allow:
      - "restarting the dev containers this project's compose file defines"
```

What you should see

Contained work runs without a card, and /rewind lists a snapshot from before the first change of the turn. This shows the controls work on your host. It does not show that the agent's change is correct, so review the diff and the check results.

What still reaches you

Some decisions never go to the judge: ask_user questions, CLIO Coder's own settings, a plan-scale dispatch, and a model edit of project settings. An approval card nobody answers within safety.unattendedAfterSeconds (300 by default) is denied, never approved, and the turn continues. A question nobody answers takes its recommended option, and /decisions shows what was chosen for you.

When to use yolo

yolo is for long jobs you leave running: nothing waits for you. It is contained by default. The sandbox, snapshots, and safety judge work as at default, and a call that would have asked you is refused back to CLIO Coder, so the job keeps going without it.

Shell

clio-coder --autonomy yolo

The first interactive activation shows a one-time acceptance card, and yolo is refused as root outside a detected container. A short floor still blocks deleting your home directory or a system tree, mkfs, writes to a block device, fork bombs, and reads of CLIO Coder's credential store. Your project's approved rules and the run's ceilings also hold. Snapshots stay on.

After 600 tool calls since you last spoke, set by safety.limits.autonomousToolCalls, the session pauses until you continue.

Unconfined yolo is the skip-permissions mode for a container or another disposable environment: nothing asks, and commands run unsandboxed with your credentials. It takes effect only with safety.yoloConfinement: unconfined in your user settings and its own one-time acceptance. The footer shows which one is active.

To keep unconfined yolo inside the sandbox, also set safety.sandbox: required. Commands then run contained, and a retry with unsandboxed: true is refused. An outward command such as git push or gh pr create leaves the sandbox only as one literal command on that tool's short option list, with no pipe, redirect, or substitution. doctor reports which rule applies.

	`default`	`yolo`, contained	`yolo`, unconfined
Shell commands	In the OS sandbox when a backend exists	As at `default`	Unsandboxed as you, unless `safety.sandbox: required`
Would-be approvals	Judge first, then you	Judge first, then refused back to CLIO Coder	None
Your questions	Wait, then resolve after the timeout	Answered at once	Answered at once
Workers	Own sandbox, asks go to the judge	Dispatched as at `default`	Own sandbox, run the yolo way in their scope
`/rewind`	Available	Available	Available

What this does not protect

The sandbox contains bash, run_script and checks that run commands through verify. Typed write and edit calls follow the rules instead.
Ignored files, untracked files over 16 MiB, and nested repositories are not in a snapshot.
/rewind restores files. It never moves refs: it prints the commands that bring a moved branch back.
The judge is a model. It can be wrong, and a route error means no verdict, so the call parks or is denied.
Stronger isolation needs an external sandbox such as a container.

By The CLIO Coder team · CLIO Coder

Continue with the documentation

Before you start

Check what this host can contain

Give it a task and watch what happens

Undo it with /rewind

Tell the judge about your machine

What still reaches you

When to use yolo