OpenAI Codex Has No Way to Block Sensitive Files from Agent Reads

Any project directory handed to OpenAI Codex is fully visible to the agent, including .env files, SSH private keys, AWS credential directories, and PEM certificates. A GitHub issue filed in August 2025 by mkusaka calls for a dedicated configuration file, .codexignore, that would let teams list paths and patterns the agent must never read or transmit to the model, modeled on .gitignore. The request covers both repository-level and global ignore files, with proposed exclusions like .env, .env.*, *.pem, id_*, .aws/**, and .ssh/**, while keeping node_modules/ accessible for implementation lookups. The core framing is about enforced policy rather than individual discipline: "Configuration should be deterministic and shareable across the team/repo."

The issue surfaced on Hacker News, drawing 120 points and 83 comments. The discussion produced a sharp technical objection: a coding agent that can execute shell commands can encounter sensitive content indirectly even when direct file reads are nominally blocked. One commenter noted an agent could invoke tools like rg foo that accidentally expose file contents in output. The prevailing counterargument was that security boundaries should exist at the OS level, through file permissions, separate user accounts, or containerized sandboxes, rather than inside Codex itself. JetBrains tools like Junie already use a .aiignore convention for agent-aware exclusion, suggesting the need is broadly recognized even without a cross-vendor standard.

The stakes for getting this wrong are asymmetric. Unlike a mistaken git commit, where credentials can be rotated and history rewritten, sending a private key to a model's server is effectively irreversible. As one commenter put it: "If you fail to prevent OpenAI from ingesting a private key, you have created a security incident." A .codexignore file would address the most obvious exposure path, direct reads, without necessarily closing every indirect route an agent might take through command execution.

The issue carries no assignee and no official OpenAI response in the retrieved material, so the timeline for any resolution is unclear. A related earlier issue was reportedly closed in favor of a Rust-based implementation that also did not ship the feature. For development teams already running Codex against real codebases, the practical question is whether to wait for a built-in mechanism or adopt OS-level isolation in the meantime.