The problem that sparked the issue

In August 2025 a GitHub issue (#2847) raised a concrete design gap in OpenAI Codex: there is no built‑in mechanism to tell the agent which files it must ignore when scanning a repository [1]. The author, mkusaka, cited two use cases – preventing accidental leakage of secrets (environment files, SSH keys, AWS credentials) and cutting out large, irrelevant binaries that waste compute. The community echoed the need for a simple exclusion file, similar to .gitignore, that could be checked into source control or applied globally.

Work‑arounds that don’t scale

Some developers have resorted to operating‑system tricks: removing read permissions, running Codex inside a container that omits sensitive paths, or deleting the files before invocation [2]. While effective in isolated scenarios, these approaches break the developer workflow. They also fail when Codex invokes auxiliary tools (e.g., make) that need access to the same files, creating a conflict between security and functionality.

Enterprise risk and cost impact

For IT directors, the lack of a declarative exclusion list translates into three concrete risks:

  1. Credential exposure – Any file present under the project root is streamed to the model, raising compliance concerns under GDPR, CCPA, and industry‑specific standards.
  2. Uncontrolled compute spend – Processing large binaries or logs inflates token counts, directly increasing API billings. OpenAI’s pricing is token‑based; unnecessary files can add up to millions of extra tokens per request.
  3. Operational friction – Teams must embed custom scripts into CI pipelines to prune directories, adding maintenance overhead and potential human error.

Community momentum for a standard

The same gap is being discussed beyond GitHub. Hacker News users pointed out that the only practical fix today is to sandbox Codex, a solution that “makes it impossible to solve perfectly” when build tools need full repository access [2]. AIWeekly highlighted a parallel effort: JetBrains’ .aiignore convention used in its Junie plugin [3]. The article notes that a cross‑vendor standard has not yet emerged, leaving the .codexignore proposal as the de‑facto reference.

What a .codexignore could look like

A minimal design would:

  • Reside at the repository root, parsed before any agent interaction.
  • Support glob patterns (e.g., *.pem, .env*).
  • Allow global config via a user‑level file (~/.codexignore).
  • Be enforced by the Codex runtime, not merely by the host OS, guaranteeing that even privileged tooling cannot bypass it.

Path forward for OpenAI

To move from discussion to deployment, OpenAI could:

  • Open a design RFC that invites contributions from the broader tooling ecosystem (JetBrains, GitHub, VS Code).
  • Implement a reference parser in codex‑rs and expose the flag --exclude-file=.codexignore in the CLI.
  • Publish a security advisory that outlines the new capability, helping compliance teams audit their usage.

By addressing the exclusion gap, OpenAI would reduce breach risk, lower token‑related costs, and make Codex viable for regulated enterprises that currently block its adoption.

Sources

  1. A way to exclude sensitive files #2847 – GitHub issue https://github.com/openai/codex/issues/2847
  2. Hacker News discussion on workaround via permissions and containers https://news.ycombinator.com/item?id=48706714
  3. AIWeekly alert on Codex lacking file‑ignore capability https://aiweekly.co/alerts/openai-codex-has-no-way-to-block-sensitive-files-from-agent-reads