openai
A way to exclude sensitive files
What feature would you like to see?
- A mechanism to explicitly mark files/paths that the agent must not read or send to the model, at both repository and global levels (e.g., a repo-local .codexignore plus a global ignore file).
- Example: keep node_modules/ searchable for implementation checks, but never read or send .env, .env.*, .pem, id_, .aws/, .ssh/.
- The configuration should be deterministic and shareable across the team/repo, and also support user defaults, rather than relying on project documentation or conventions.
Are you interested in implementing this feature?
- Yes — I can contribute and tests.
Additional information
Related: #205. That issue surfaced two primary use cases: preventing sensitive data from being sent to the model and excluding large/irrelevant files. The issue was closed in favor of a Rust (codex-rs) implementation, but as of 2025-08-28 a comparable feature does not appear to exist in codex-rs. I’d like to restart the discussion and converge on a design.
.agentignore would be better - more tool agnostic, now that AGENTS.md has been adopted by multiple tools including Codex. Cline uses .clineignore, Cursor uses .cursorignore and .cursorban . There's a similar feature request for Cline : https://github.com/cline/cline/discussions/5887 .
Based on my tests, there seems to be no way to prevent Codex from uploading all files into OpenAI, regardless of .gitignore or AGENTS.md. If Codex decides to use rg or grep and finds some relevant content in a file, it will be uploaded.
+1 for adding this feature, it is important not only for protecting confidential data, but also for preventing Codex from uploading tons of irrelevant stuff, such as caches, node_modules, types, etc.
+1. It is very important for some corporations and projects to ensure that agents do not indiscriminately ingest everything, including sensitive data or keys.
Hello, I suggest using the same approach as Google to exclude certain folders from the context .aiexclude. So, if we switch from gemini-cli to codex or another CLI AI, it will simplify the developer's life.
https://cloud.google.com/gemini/docs/codeassist/create-aiexclude-file
This feels like table stakes for any security-minded organization that doesn't want Codex to indiscriminately upload keys, secrets, environment variables, passwords, etc to OpenAI servers where they are potentially stored permanently. Claude code makes this trivial via settings.local.json with "deny": [ "Read(.secret-dir)" ].
I totally agree with this issue. Right now, even if gitignored files cannot be referenced with @, the agent can still read sensitive files both through the Read tool and via shell commands (rg, cat, etc.).
This means that the only way to achieve a proper level of security is to enable protection at the sandbox level, completely removing those files from the Codex execution context.
On macOS, I tested a solution leveraging sandbox-exec (which Codex internally uses). I’ve expanded on this in a discussion: [GitHub Discussion #5523](https://github.com/openai/codex/discussions/5523).
(version 1)
(allow default)
(deny file-read* (regex "\.env$"))
(deny file-write* (regex "\.env$"))
This works correctly — running sandbox-exec -f deny-env.sb codex prevents Codex from reading the contents of .env files. However, it’s a somewhat hacky solution and should ideally be handled natively within Codex itself.
After discussing with ChatGPT (somewhat meta 😄), it suggested an alternative using Landlock on Linux, based on an allowlist model. I need to investigate it further, but Landlock seems the right long-term mechanism, as it is already used internally by Codex.
Implementing such protections is crucial to ensure a safe development environment.
Another issue also discusses this problem and contains additional proposals: [GitHub Issue #1397](https://github.com/openai/codex/issues/1397).
Considering Claude Code has a 5 seat minimum for teams, which my company doesn't meet yet... we'd move to Codex for Teams in a heartbeat with this feature for the business license. We're holding back (and considering Gemini code assist), because Codex lacks a deterministic permissions system.
Does this issue qualify as a security concern (my opinion: it should) for the purposes of welcoming a contribution as per the contributor guidelines?
+1, this is such a basic aspect, I'm surprised it hasn't been implemented yet!
Please add this feature, its a basic security and performance issue. I don't want Codex reading everything in my codebase and sometimes, like to keep PRDs and Plan files in my repo for future reference that are outdated and confuse the model, which as of now I have no way of restricting.
This is the first thing should implemented before the release. ⚠️ Ignoring this issue will increase current distrust toward openai.
This is the first thing should implemented before the release. ⚠️ Ignoring this issue will increase distrust toward openai.
100% agreed. I installed codex in my IDE this week assuming this would be a feature, and I have now uninstalled it. The fact that it wasn't included in the first release has very much increased my distrust towards openai.
Claude Code and Gemini have both implemented this feature, so why isn't Codex considering it? I really want this feature.
was planning to try out codex and found this, can't use it without this, very surprised to find out it doesn't have it, also doesn't give much trust in that it won't creep out into other paths that it shouldn't be allowed to access.
⚠️ This is a Critical Data Leakage. They are ignoring this first must-have feature.
Is there a timeline or any kind of information when this feature request is getting implemented. You can't take that seriously. How are you supposed to use Codex in customer projects?!
@etraut-openai Tell dev team to implement it ASAP
This is a true TROJAN HORSE: Codex reads files outside working directory without my permission
Commenting to bump this again, deterministic file exclusions is absolutely crucial for Codex. I would venture to say nearly every piece of modern software has some sort of sensitive env variables, secret keys, etc that need to stay prviate and cannot be ingested by LLMs.
Since OpenAI doesn't seem to want to implement this, I built a jail for it instead: https://gist.github.com/mnpenner/137ccdccf7619dfc403c53ddd1b626e6
This exposes your project dir to codex but hides most of the rest of your filesystem and makes it read-only so it can't wreak too much havoc.
I want to mask over private files inside the project dir too but I haven't figured out how to do that yet without mounting a ton of empty files over everything. If anyone has suggestions for that, please LMK in the gist comments.
