OpenAI Codex: Excluding Sensitive Files Is Still an Open Problem

Using OpenAI Codex in your development workflow and wondering what the agent can actually read in your repository? That’s a fair question. An open issue on the official repository highlights a security gap that many developers haven’t thought through yet.

OpenAI Codex and Sensitive Files: The Concrete Problem

On August 28, 2025, a developer named mkusaka opened issue #2847 on the official openai/codex GitHub repository. The request is straightforward: there is no native mechanism to prevent the Codex agent from reading or sending sensitive files present in a project to the model.

In practice, Codex can access files like .env, .pem, private SSH keys, and directories like .aws/ and .ssh/. There is no deterministic configuration to block this. For any developer running Codex on a codebase that contains secrets, this is a real security blind spot.

The issue is still open at the time of publication. It’s labeled enhancement and sandbox, which signals that OpenAI acknowledges the concern without having delivered a solution yet.

What the Community Is Asking For

The issue author proposes a mechanism inspired by .gitignore: a configurable .codexignore file that works at two levels.

Repository level: a local .codexignore file, shareable with the team through version control.
Global level: a user configuration file, applicable across all projects on a given machine.

The idea is to allow granular rules. For example, letting Codex explore node_modules/ to check implementations, while explicitly forbidding it from reading .env, .env.*, id_rsa, .aws/, or .ssh/. The configuration must be deterministic, shareable, and not rely on informal documentation conventions.

The author also notes that a similar issue (#205) had been closed in favor of an implementation in codex-rs (the Rust rewrite). As of August 28, 2025, that feature still doesn’t exist in codex-rs. Issue #2847 aims to reopen the discussion and converge on a concrete design.

Why This Is a Serious Security Concern

AI coding assistants have access to far more context than a plain text editor. When an agent reads a file to send it to a remote model, that data travels through third-party infrastructure. Without an explicit exclusion mechanism, several risks emerge.

Secret leakage: API keys, OAuth tokens, database credentials.
Exposure of private certificates and SSH keys.
Unintentional transmission of configuration files containing infrastructure details.
No way to audit what context the model actually received.

This isn’t a theoretical risk. .env files are present in the vast majority of modern projects. Without a .codexignore, teams are forced to rely on conventions rather than a verifiable technical configuration.

Workarounds Available Today

With no native solution in place, developers have to improvise. A few common approaches exist, but none of them hold up well at team scale.

Store secrets outside the working directory, in locations that aren’t indexed.
Use environment variables injected at runtime rather than .env files committed or present on disk.
Restrict system-level permissions for the Codex process through external sandboxing solutions.
Document which files should not be exposed in the README, which relies on human discipline rather than a technical constraint.

None of these options replace a built-in, deterministic, and auditable mechanism.

Where Does OpenAI Stand on This?

The issue remains open with no assignee and no official response documented in publicly available data. OpenAI has not published any roadmap announcement specifying when or whether this feature will be implemented. The sandbox label suggests the product team has it on their radar, but there’s no public commitment on a timeline.

The openai/codex repository has accumulated more than 94,000 stars on GitHub, which reflects massive adoption. A security gap in a tool this widely used deserves a fast and well-documented response.

Key Takeaways

Issue #2847 on openai/codex flags the absence of a native mechanism to exclude sensitive files from the context sent to the model.
The request centers on a .codexignore file at two levels: repository and global user.
Critical files like .env, .pem, SSH keys, and AWS credentials are potentially readable by the agent without any configured restriction.
A previous attempt (issue #205) was closed without an effective implementation in codex-rs.
As things stand, no native technical solution exists: workarounds depend on team discipline, not technical guarantees.

If you’re using Codex in production, now is the time to audit what the agent can reach in your repositories. If this topic interests you or you’ve put concrete solutions in place, let’s talk in the comments or follow the blog for upcoming analyses.