Sandbox: shown by running it
You do not have to take the sandbox on trust. One subcommand runs any command inside it, with no model call, so you can watch what it refuses.
codex sandbox -- <command>That runs the command under the same boundary the agent gets, and nothing else: no model, no tokens, no account.
Reading is allowed
codex sandbox -- python3 -c "print(open('notes.txt').read().strip())"hello
The file was read and printed. That is the normal case: the agent spends most of its time reading, and none of that needs your permission.
Writing is not, by default
codex sandbox -- python3 -c "open('inside.txt','w').write('ok')"PermissionError: [Errno 1] Operation not permitted: 'inside.txt'
Inside the project folder, and still refused. The default here is read-only, and read-only means everywhere rather than only outside your work.
And neither is anything outside the folder
codex sandbox -- python3 -c "open('/tmp/outside.txt','w').write('ok')"PermissionError: [Errno 1] Operation not permitted: '/tmp/outside.txt'
Same error, different place. The boundary is not a warning or a policy the agent chooses to follow: the operating system refuses the call. On macOS that is Seatbelt, on Windows the native sandbox, and on Linux and WSL2 it needs bubblewrap installed.
Why this is the first lesson
- Refusals stop being mysterious. A blocked command is the boundary working, not the tool being awkward.
- You can test a rule before trusting it. Anything you are about to allow, run here first.
- It costs nothing. No model, no tokens, no account.
- Run the three commands above in one of your own repositories.
- Try a command you would be nervous about, safely, inside
codex sandbox.
Slow is fine. Stopping is the only problem.