AI Coding Agent File Security: The 10-Month Crisis of Codex Issue #2847
AI Coding Agent File Security: The 10-Month Crisis of Codex Issue #2847
Imagine this: you fire up Codex CLI in your project directory to refactor a database module. The agent reads your entire codebase — including .env, .pem keys, and .aws/ credentials — and sends them to OpenAI’s servers. There is no switch, no setting, no ignore file to stop it.
That’s not a hypothetical scenario. It’s the current state of OpenAI’s Codex CLI, documented in GitHub Issue #2847, which has been open for 10 months with 441 upvotes and 84 comments — and zero published progress toward a fix.
The Problem: Codex CLI Reads Everything
Issue #2847, opened August 28, 2025 by a contributor, lays out the gap clearly:
“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.”
The request is straightforward: a mechanism to explicitly mark files and paths the agent must not read or send to the model — at both repository and global levels. Think .gitignore but for AI agents. The patterns users want to exclude are predictable: .env, *.pem, id_*, .aws/**, .ssh/**, secrets/, and private keys.
The issue carries two labels — enhancement (feature request) and sandbox (permissions-related). Despite being flagged as a security concern by multiple users, OpenAI has not reclassified it as a security issue or CVE. In fact, the academic paper “Shifting Information and Control to Filesystems for Agent Safety” (arXiv 2604.13536) explicitly cites this issue as evidence that Codex lacks basic file access controls.
How Codex Bypasses Common Exclusions
Codex can access sensitive files through multiple vectors:
- File system tools — The agent’s built-in file reading tools scan all accessible paths
- Shell commands — Via
rg,cat,grep, and other commands the agent can invoke at will - Outside working directory — Issue #5237 documents Codex reading files outside the specified working directory, including personal files on the developer’s Desktop
One developer who tested sandbox restrictions reported:
“Codex first tries to run commands inside the sandbox, and when that does not work it runs the same command ‘with escalation’ and then it works. This means Codex can still read everything.”
The escalation bypass means sandbox-level restrictions don’t compose with the permission override system. Even the partial workaround — setting ~/.codex/config.toml filesystem restrictions — can be defeated by Codex’s own auto-escalation behavior.
Corporate users reported dire consequences:
“In my company, we just reverted the recommendation of using Codex CLI because of this missing feature. It is the major blocker for enterprise users.”
“This makes Codex unusable for us at the moment. We will switch to another tool.”
The Codex team explicitly rejected an external pull request that addressed this issue, closing it as “unsolicited code contributions” — a policy that prevents the community from fixing the gap themselves. Community forks like xCodex and MukundaKatta/codex have since implemented exclusion support independently, proving the implementation complexity argument doesn’t hold water.
The Competitors: Everyone Else Solved This
Every major AI coding assistant shipped file exclusion long before Codex:
| Tool | Exclusion Mechanism |
|---|---|
| Claude Code | permissions.deny in settings.json — ship-day feature |
| Cursor | .cursorignore — ship-day feature |
| Cline | .clineignore — ship-day feature |
| Gemini CLI | .aiexclude — ship-day feature |
| GitHub Copilot | .copilotignore — shipped early 2024 |
| Codex CLI | ❌ Nothing — still missing (June 2026) |
To be clear, Claude Code’s deny rules have also been reported as potentially bypassable. But the key difference is Claude Code has the mechanism — teams can set up policies, audit them, and get a baseline. Codex doesn’t even offer the attempt.
The fragmentation itself has sparked a standardization effort: .agentignore is a proposed vendor-neutral ignore file format. The spec wisely cautions that ignore files reduce accidents but don’t replace OS-level security boundaries. But even that accident-reduction layer is missing in Codex.
The OpenAI Response
An OpenAI employee finally responded on the issue in March 2026:
“We understand this is an important feature. We generally prioritize features based on upvotes from the community. A month ago, this feature was somewhere around 15th in the priority queue. We’ve been steadily delivering new features based on that prioritization approach. This feature is now near the front of the queue, and we’re actively working on it.”
The community response was blistering:
- Relying on upvote priority in an 84K-issue backlog means security features never float to the top naturally
- External PRs rejected — the “unsolicited contributions” policy makes it impossible for the community to help
- Fixes exist — multiple forks have proven the implementation is straightforward
One commenter noted:
“This behavior constitutes an insecure default that can expose confidential data to the model and any downstream logging or storage, creating an information-leak vulnerability.”
Another added:
“It’s 2026 and this has been totally ignored more than half a year. It was the first feature Claude, Gemini, and others implemented. The irony that this has been ignored for so long is a meme.”
The Enterprise Impact
This isn’t developer convenience — it’s a compliance blocker. Enterprise security teams assess AI tools against SOC 2, GDPR, and CCPA frameworks, all of which require data minimization: processing only the data strictly necessary for function.
Codex CLI fails this gate by design. Approving Codex means authorizing developers to transmit — unredacted — every file in every project to OpenAI’s servers. For companies handling PII, PHI, or trade secrets, that’s an automatic disqualifier.
Developers are voting with their feet. Multiple commenters reported switching to Claude Code, Qwen CLI, or Gemini CLI specifically because of this gap. The irony is stark: OpenAI created the Codex model that powered the AI coding revolution, yet their own implementation can’t match the security baseline competitors set years ago.
Workarounds for Today
While waiting for OpenAI to ship, there are limited workarounds:
~/.codex/config.toml— Set a sandbox permission profile restricting file access. Note: escalation bypass may still work.- macOS
sandbox-exec— Create a policy file blocking sensitive paths. Effective but requires manual setup. - Docker isolation — Run Codex inside a container mounting only specific directories.
- Community forks — Try xCodex or other forks that add exclusion support.
None of these work at team scale. The real fix requires OpenAI to ship .codexignore (or adopt .agentignore) with OS-level enforcement — not a “best effort” approach that tools can bypass.
The Bottom Line
Issue #2847 is the most visible symbol of AI coding tool security’s biggest gap. Ten months, 441 upvotes, 84 comments, proven fork implementations, an academic paper citation — and the official response is “it’s in the queue.” Every competitor shipped this feature on day one. Several forks proved it’s trivial to implement. Only OpenAI’s own tool refuses to give developers control over what their AI agent reads.
Until Codex ships deterministic file exclusion, it’s not an enterprise-ready tool. And the longer this gap persists, the more trust — and customers — OpenAI concedes to competitors who treated security as table stakes from the start.
← Back to all posts
