Add read-restricting sandbox mode for Codex CLI
Description
Today the sandbox only blocks writes (and optionally network); reads are always allowed
(see codex-rs/linux-sandbox/src/landlock.rs TODO about has_full_disk_read_access and the
unconditional access_ro rule for "/"). I’m using Codex as a shell executor in the
openai-agents-python project and need to confine filesystem reads to a specific folder
(like a chroot/bwrap view) so the model cannot inspect the rest of the host.
Request
add a sandbox policy that constrains read access to declared roots, across macOS Seatbelt
and Linux Landlock, including CLI flags/config so the allowed paths can be set explicitly.
Motivation
Security/privacy: prevent the model-driven shell from reading secrets or unrelated files
outside a designated workspace. This complements the existing write and network controls
and removes the need for external containers/bwrap just to restrict reads.
Acceptance Criteria
- New sandbox mode/config flag that limits readable roots; defaults preserve current behavior.
- On Linux, Landlock rules omit access_ro to "/" unless explicitly allowed; on macOS, the
Seatbelt profile mirrors the same read constraints.
- CLI/docs updated to show how to launch Codex with a read-limited workspace root.
Additional information
_No response_
2 Comments
This is related to https://github.com/openai/codex/issues/2847.
Restricting all reads is problematic because all tool execution necessarily involves reads outside of the workspace. That takes you down the path of allowing read access for specific known directories, but there will be a long tail of execution failures for tools that read outside of known directories.
If you want this level of restriction, you're probably better off running codex in an isolated docker container or VM.
We can leave this feature request open for brainstorming purposes, but I'm not optimistic that we'll find a solution that strikes a good balance in terms of usability and safety.
Thanks for the response. I see that this is a common request. No need to keep this issue open. You all are definitely aware of the request. I see there are a lot of similar read restriction issues. I will look into running the python agent in a docker container or VM. I have found that a system prompt seems to keep GPT 5.1 from reading outside of the workspace that I tell it to stay in. I'm sure that approach is not infallible but it's probably good enough for my purposes. I'll keep my ears to the ground, who knows, maybe someone will figure something out.