Codex/XLI separates where commands may run from when the user must approve them.
- Sandbox mode controls the execution environment.
- Approval policy controls consent and escalation behavior.
You usually want to think about both together.
| Mode | Intended use |
|---|---|
read-only |
Inspect the repo without changing files |
workspace-write |
Allow edits inside the workspace while keeping stronger isolation |
danger-full-access |
Disable the normal sandbox; only use inside another trusted isolation boundary |
The CLI also exposes a dedicated flag:
xli --sandbox read-only
xli --sandbox workspace-write
xli --sandbox danger-full-accessIn workspace-write, the runtime also includes the active memories path in the
writable roots so memory maintenance does not require a separate approval step.
In the XLI launcher, that usually means ~/.xli/memories.
Common policies include:
| Policy | Behavior |
|---|---|
on-request |
Ask when a command needs escalation or broader permissions |
on-failure |
Try in the sandbox first, then escalate if needed |
unless-trusted |
Escalate most commands except a small allowlist of safe reads |
never |
Do not request approvals; stay within the configured sandbox envelope |
Exact behavior can vary with the environment, but this is the right mental model when you are choosing a session profile.
The sandbox subcommand is useful when you want to see how a command behaves
under the host sandbox without running a full agent session.
xli sandbox -- pwd
xli sandbox --log-denials -- cat /etc/hostsThe subcommand also accepts --profile NAME so you can test with a named
config overlay.
- Use
read-onlyfor review, reconnaissance, and architecture questions. - Use
workspace-writefor normal implementation work. - Reserve
danger-full-accessfor environments that are already isolated by some other control, such as a disposable container.
- execpolicy.md for command-specific policy rules
- config.md for
approval_policyandsandbox_mode ../codex-rs/README.mdfor the CLI surface