Codex reads files outside working directory without my permission

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #5203
• #4410
• #4152

Powered by Codex Action

Adding a screenshot for convenience

<img width="2580" height="1768" alt="Image" src="https://github.com/user-attachments/assets/20715aec-9ef5-4b0c-a353-32b56dc03138" />

I don't believe the duplicates fully cover this issue.

The codex sandbox is designed to prevent file system writes outside of your working directory. It does not prevent reads. It wouldn't be usable if reads weren't supported. For example, no tools would be able to run in that case. If you want to fully isolate the agent, we recommend that you run it in a docker container or VM.

For example, no tools would be able to run in that case.

That argument is kinda flawed because $PATH exists? If you need to make any other exceptions, codex or the user should define those.

I really thought codex was more secure than others like CC because of the sandbox, but if you're not making effective use of it, it wouldn't matter.

If it is expected behavior that the agent can read any file the user has access to without asking for permission, this is IMO not well documented. On the contrary, I'm pretty sure most people who read https://developers.openai.com/codex/security/ will think that read access without approval is restricted to the workspace by default:

We’ve chosen a powerful default for how Codex works on your computer. In this default approval mode, Codex can read files, make edits, and run commands in the working directory automatically. However, Codex will need your approval to work outside the working directory or run commands with network access.

I think that in the majority of cases, codex-cli will be run on a user account which also has access to credentials (e.g. ~/.ssh/*) or personal information which should not be read by the agent (because that means it's sent to a remote server for processing). It is IMO reasonable to want built-in safeguards against this, e.g. by restricting which files codex-cli can read without approval to the workspace.

Yes, tool calls also read files outside the workspace, both because the tools themselves are usually outside the workspace and because arbitrary tool calls have this capacity. Perhaps that means that the sandbox is the wrong place to add these restrictions - I don't know enough about how it works. However, it does not make it impossible to provide better read access safeguards, just that they would require more nuanced rules than "literally only allow the process to read files inside the workspace".

So please consider

• re-opening this issue, perhaps as a feature request instead of a bug
• improving the documentation to make it clear that the agent can currently read anything the user can read, regardless of sandbox settings

I agree with @Medo42 but want to highlight that in the order they are shown these sentences are not just likely to be read by most people as not allowing codex to read outside the working directory but appear written to cause that impression!

In this default approval mode, Codex can read files, make edits, and run commands in the working directory automatically. However, Codex will need your approval to work outside the working directory or run commands with network access.

The opposition of "read files" in a list of things it can do to "work outside the working directory" as seemingly-generic term which actually excludes reads is bound to confuse and surprise.

It wouldn't be usable if reads weren't supported. For example, no tools would be able to run in that case.

Can you say more about this? the vast majority of my coding agent sessions do not involve any reads or writes outside the current working directory. Why would "no tools" be usable? I'd expect every tool to work exactly the same, except if it tries to read a file outside the working dir the sandbox would error the tool out.

Why would "no tools" be usable?

The tools themselves are files on disk that need to be readable (and executable), and many tools require access to configuration files that also need to be readable. If the sandbox prevented all reads outside of your workspace, every attempt to invoke these tools would fail.

> Why would "no tools" be usable? The tools themselves are files on disk that need to be readable (and executable), and many tools require access to configuration files that also need to be readable. If the sandbox prevented all reads outside of your workspace, every attempt to invoke these tools would fail.

Those paths should be largely known though. Is there any reason to allow reading the entire home directory for instance? That usually contains the most sensitive information on any particular machine, like ~/.ssh/, ~/.gnupg/ or ~/.mozilla/. If a tool must create and read a (config) file inside the home directory, it should be achievable via a virtual home directory.

That's not how our current sandboxing mechanisms work. It sounds like you're looking for finer-grained configurability and more restrictive defaults. Feel free to upvote this issue or create a new feature request if you don't think it captures what you're looking for.

Finding the right balance between "overly restrictive" and "not restrictive enough" is difficult with creating a sandboxing policy. If you dig through the codex issue tracker, you'll find many bug reports about tool failures because the current sandbox policy is overly restrictive. Also, keep in mind that codex runs on linux, MacOS, Windows (native) and Windows (WSL), and we try to maintain feature and behavioral parity across platforms.

This sounds as nightmare, why this issue is closed?

> Why would "no tools" be usable? The tools themselves are files on disk that need to be readable (and executable), and many tools require access to configuration files that also need to be readable. If the sandbox prevented all reads outside of your workspace, every attempt to invoke these tools would fail.

Why not provide an allow list of accessible folders? That should suffice, it keeps the rest of the system secure from exfiltration, it allows you to run in 'yolo' mode within a repo (with network off hopefully...). This is the biggest pain point in using codex right now.

@etraut-openai Hi and Merry Christmas!

You wrote:

Finding the right balance between "overly restrictive" and "not restrictive enough" is difficult with creating ...

This statement creates a false dichotomy, because there are other options besides these two. For example, configuration.
Permissions should be configurable. Allow list and block list is a basic feature of access control and it is trivially to do! On each read, write, execute action, the list should be checked, and appropriate decision should be made.

If you dig through the codex issue tracker, you'll find many bug reports about tool failures because the current sandbox policy is overly restrictive.

This statement also cannot be used as an excuse for not implementing customizable permissions. It is possible to handle access errors and display clear error messages for humans.
Default permissions configuration can be whatever you think is good for the OpenAI Codex, but for power users it should be able to configure access control rules.
Let people decide which trade-offs in convenience vs security pair they want to do.

I think closing this without even acknowledging the documentation issue is a bad look for the tool. The documentation should be a lot more clear on this. As it's written now it appears to be deliberately misleading, with an "escape hatch" in that it _could_ (but won't) be interpreted to describe the current behavior.

Just spell it out: "Regardless of the sandbox settings, Codex can always read all files the executing user has permission to read."

+1. After using codex for a while assuming it can't read files outside of workspace I dreadfully learned that it is not the case.

Seriously. How can we ever avoid AI-doom if 'not stealing our secrets/credentials' is only matter of 'convention followed nicely by AI model'? There needs to be some workspace-only isolation for codex to be a serious tool.

You can build a docker image w/ codex installed, mount the local directory in, and add a bash alias to launch it.

ccodex() {
  docker run --rm -it \
    -e HOME=/home/dev \
    -v "$PWD:/workspace" \
    -v "$HOME/.codex:/home/dev/.codex" \
    CODEX_IMAGE_NAME "$@"
}

Interested in if anyone can see any glaring issues w/ this approach.

You can build a docker image w/ codex installed, mount the local directory in, and add a bash alias to launch it. `` ccodex() { docker run --rm -it \ -e HOME=/home/dev \ -v "$PWD:/workspace" \ -v "$HOME/.codex:/home/dev/.codex" \ CODEX_IMAGE_NAME "$@" } `` Interested in if anyone can see any glaring issues w/ this approach.

I do something similar but I mount ~/.codex/ as read-only. Given the tenacity of the 5.2 models and their intelligence, it's not a stretch to imagine that if the prompt injection is good enough to fool them, it would also successfully convince them of trying _absolutely everything_ including the editing of the instructions under ~/.codex/. Maybe it's a bit tinfoil-hatty but I don't want to be the first to be pwned by this.

I suggest instead of painful tricks, ping the company members.
@etraut-openai Explain the bugfix time of this security bug

As I explained above, we don't consider this a bug. The Codex sandboxing mechanism is working as designed.

There is an open feature request that you can upvote if you'd like to see it work differently. That feature request has already received lots of upvotes, and we're exploring ways to implement some of the suggestions, but this isn't a simple feature request. It involves many complex tradeoffs. It's also complicated by the fact that we want sandboxing behaviors to be relatively consistent across the three platforms that Codex supports (macOS, Linux and Windows). Each platform has different sandboxing / isolation mechanisms with different limitations.

In the meantime, if you want stronger isolation guarantees, we recommend running Codex in a docker container or VM.

@santiago-afonso: That's a great idea, the more precaution the better! How are you handling auth? Logging in outside of the container and then running?

1. I will translate.

Finding the right balance between "overly restrictive" and "not restrictive enough" is difficult with creating a sandboxing policy.

You guys don't mind if codex reads any stuff by chance from our computer into your API, including secrets. No thanks.

As I explained above, we don't consider this a bug.

You guys don't mind either if an attacker steals our secrets. What about prompt injections, are they no problem in 2026 anymore? Yes, they are still? Then where are your high standards of security?

1. This is another thing that Anthropic does just fine, by popping a yes/no question for every access outside the CWD.

1. Until you fix it, we're gonna sandbox.

For those who prefer bwrap, here's my command (based on a version for CC)

PROJECT_DIR="$PWD"
bwrap \
--ro-bind /usr /usr \
--ro-bind /lib /lib \
--ro-bind /lib64 /lib64 \
--ro-bind /bin /bin \
--ro-bind /etc/resolv.conf /etc/resolv.conf \
--ro-bind /etc/hosts /etc/hosts \
--ro-bind /etc/ssl /etc/ssl \
--ro-bind /etc/passwd /etc/passwd \
--ro-bind /etc/group /etc/group \
--ro-bind "$HOME/.gitconfig" "$HOME/.gitconfig" \
--bind "$PROJECT_DIR" "$PROJECT_DIR" \
--bind "$HOME/.codex" "$HOME/.codex" \
--ro-bind "$HOME/.nvm" "$HOME/.nvm" \
--tmpfs /tmp \
--proc /proc \
--dev /dev \
--unshare-all \
--share-net \
--die-with-parent \
--chdir "$PROJECT_DIR" \
codex "$@"

How do you guys trust codex?

It continues to modify files even though I asked it to show me the diff. I asked it to memorize it, yet it continues to ignore this fact.

It happens continuously.

this is what it says:

Yes. on-request does not mean “always ask before modifying files.” It means the model may execute actions inside the sandbox without asking, and it only requests approval when it decides it is needed or when escalation outside the sandbox is required. So an apply_patch on files inside the workspace can happen without a prompt. The problem here was not the on-request policy. The problem was that I did not follow your additional operating rule: show you the diff first and wait for your ok.

so it does whatever it wants, great tool

That's not how our current sandboxing mechanisms work. It sounds like you're looking for finer-grained configurability and more restrictive defaults. Feel free to upvote this issue or create a new feature request if you don't think it captures what you're looking for. Finding the right balance between "overly restrictive" and "not restrictive enough" is difficult with creating a sandboxing policy. If you dig through the codex issue tracker, you'll find many bug reports about tool failures because the current sandbox policy is overly restrictive. Also, keep in mind that codex runs on linux, MacOS, Windows (native) and Windows (WSL), and we try to maintain feature and behavioral parity across platforms.

Can you just copy claude code behaviour in cli? it works perfectly!

Is there a way to block certain dirs? I like the worktree isolation and would prefer it not to have access to my master local env files so that it doesn't potentially wreck a local dev db with an integration test that runs unattended.

@pthun :

Is there a way to block certain dirs? I like the worktree isolation and would prefer it not to have access to my master local env files so that it doesn't potentially wreck a local dev db with an integration test that runs unattended.

Yes, through sandboxing. See the posts above for docker, bwrap.

No, this is not built-in. As the Codex team expressed, they want to keep Codex to be able to read any file on your PC. See also other bug reports, like: https://github.com/openai/codex/issues/2847

I see @ha7ilm thanks for the extra context.

I also use the Codex macOS app alongside the terminal application (great job there designing that codex team) so I think docker or bwrap won't work for that.

As most sensitive data is in the home directory I think what I will try to do is just run Codex as a separate user with an empty user directory, has anyone tried that successfully. I think that basically gets me the OS-level equivalent of "you may not read these directories"? Or am I missing anything

You can use ~/.codex/config.toml to achieve this, here's what mine looks like. I'm on MacOS, the sandbox works a bit different on each OS.

approvals_reviewer = "user"
approval_policy = "on-request" # any of these restrictions can be bypassed with user approval. if you set this to "auto-review", these restrictions can be bypassed with reviewer agent approval
sandbox_mode = "workspace-write"
default_permissions = "workspace_only" # create a custom permissions profile

[permissions.workspace_only.filesystem]
":minimal" = "read" # minimal access required for codex to operate
"/Library/Developer/CommandLineTools" = "read" # required for git
":project_roots" = "write"
"/tmp" = "write"
"~/.cache/uv" = "write" # required for codex to use uv without approval

[permissions.workspace_only.network]
enabled = true
mode = "full"

[shell_environment_policy]
inherit = "core"
exclude = ["*_KEY", "*_TOKEN", "*_SECRET", "*_PASSWORD", "AWS_*"]

Note that ":project_roots" = "write" allows codex to modify your code workspace without asking approval, if you set this to "read" you must also set all other "write" directories to "read"

You can also add project overrides in .codex/config.toml files.

@ahalekelly is there Official docs for this?

Yeah the docs are here: https://developers.openai.com/codex/config-reference

It looks like these options were only added in early March, they've been overhauling the permissions system

@ahalekelly this solution does not work with either Codex CLI or Codex app.

@etraut-openai having this behavior in codex is a security nightmare. We need an option to overwrite this. Please don't tell that it's not possible, because it works well in Claude Code.

don't close this please. please don't follow anthropic way of talking with users @tibo-openai plz 🙏

There is an active feature request: #2847. Please upvote if you'd like to see this feature.