.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 .

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

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.

need it too

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

Please implement it! It is very important for security!

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

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?

I've contributed to agent-box which allows you to bind-mount git repositories into containers that agents operate in, preventing the agents from accessing files that aren't bind-mounted. Your usual .gitignore can then be used to also ignore files within the repo to be bind-mounted, which prevents agents from accessing them at all, essentially working as a sandbox.

I also maintain agent-images which allows you to use Nix to reproducibly spin up OCI containers containing agents and any other tools you need and use these with agent-box.

I use both at the moment to work on some personal projects with agents, where I set up multiple separate git worktrees for the agents to work in, preventing them from accessing anything outside of the worktrees and from trampling over each other's work.

Sorry, I didn't realize this issue was open or I would have commented sooner, but we have had a solution for a number of months now, though we have been tweaking the config language here and there, which is why it is still tagged as "Beta" in the docs:

https://developers.openai.com/codex/permissions

You can use /permissions in the CLI to change the permission profile at runtime. We're still working to ensure things work equally smoothly in Codex App (which has more places where an agent loop gets created than the CLI, so the change is a bit more complex).

Okay i've done it like so:
added: repo-root/.codex/config.toml

default_permissions = "xxx-workspace"

[permissions.xxx-workspace.filesystem.":workspace_roots"]
"." = "write"
"out of context file here..." = "deny"

I'm going to close out this feature request. As @bolinfest mentioned above, we have a new feature in beta that implements this functionality. If you have follow-on bug reports or enhancement requests, please open a new issue.