OpenAI's Codex is a command line coding agent with no built in .gitignore style deny list for credential files. The vendor's answer is sandbox isolation, which governs what the agent can do, not which files it can read.
OpenAI's Codex coding agent reads the files in your repository to suggest changes. It does not, today, let you tell it which files to leave alone. A still-open enhancement request on the openai/codex repository asks for exactly that: a .codexignore file at the repo level and a global ignore file, so patterns like .env, .env., .pem, id_, .aws/, and .ssh/ are never read by the agent or sent to the underlying language model.
A .codexignore would behave like a .gitignore: a deterministic, shareable configuration file that any developer on the team can rely on, plus a user-level default that travels across repositories. The issue's author argues that documentation and convention are not enough. The whole point of a deny-list is that it is enforced by the tool, not by the user remembering what not to open.
This is not the first time the request has surfaced. According to the #2847 thread, predecessor issue #205 raised the same two use cases: prevent sensitive data from being sent to the model, and exclude large or irrelevant files. #205 was closed in favor of the Rust-based rewrite of Codex, codex-rs. As of 2025-08-28, the issue text observes, a comparable exclusion feature does not appear to exist in codex-rs either. That is the filer's own observation, not a statement from OpenAI.
The vendor's answer, in the meantime, sits one layer up. OpenAI's Codex sandboxing documentation describes container- and OS-level isolation that controls what the agent can do at runtime: which processes it can spawn, which network destinations it can reach, which filesystem paths it can write. The Codex configuration reference layers additional knobs on top. Neither is a file-pattern deny-list. Both are sandbox policies that operate regardless of file name. A sandbox can keep Codex from exfiltrating data over the network; it does not, by itself, keep Codex from opening a .env file when it greps the working tree.
That is the gap a .codexignore is supposed to close, and the Hacker News discussion of the request makes clear why the question has been hard to settle. Labeled practitioner commentary on the thread objects that any static deny-list is leaky. Ripgrep across the repository, build tools like make that legitimately need the file, environment variables propagated through subprocesses, and container mounts that surface the file under a different name all bypass the pattern. Commenters also point to workable existing controls: making the file unreadable to the codex process with Unix permissions, deleting the file, keeping it out of any mounted path, or relying on harnesses that already block direct reads of .env through their edit and read tools.
The disagreement is about where the boundary should live. Developers want a configuration file they own, because configuration files travel with the team and survive handoffs. OpenAI's Codex is built around a sandbox, because the vendor's threat model is about what the agent can do at runtime, not what it can see. "It runs in a sandbox" is a statement about process and network containment. "It will never read my .env" is a statement about file-pattern policy. Codex currently offers the first. The open enhancement request, and the Rust rewrite that absorbed the closed predecessor, are where the second is being asked for.
The issue is still labeled enhancement and sandbox, still open, and still accumulating comments that argue about the design rather than the premise. Whether it ships as a .codexignore file or as a configuration flag inside the existing config reference, the request has now survived one codex-rs release cycle without a resolution, and that persistence is itself the news.