A way to exclude sensitive files

[mkusaka]

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.

[torson]

.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 : cline/cline#5887 .

[tcgumus]

so there isn't anyway to prevent sensitive data to reach codex right now?

[vacavaca]

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.

[dunkel000]

+1. It is very important for some corporations and projects to ensure that agents do not indiscriminately ingest everything, including sensitive data or keys.

[booyoi]

need it too

[numlock1052]

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

[chan-jui-huang]

Please implement it! It is very important for security!

[prettymuchbryce]

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)" ].

[ilmeskio]

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](#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](#1397).

[codeblooded]

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.

[jbalonso]

Does this issue qualify as a security concern (my opinion: it should) for the purposes of welcoming a contribution as per the contributor guidelines?