A year later, OpenAI Codex still can't be told to skip your .env file
Someone opened issue #2847 asking Codex for a simple .codexignore so the agent would never read .env, *.pem or .ssh keys. The thread's verdict: even if OpenAI shipped it, it would be security theater.
The request is modest: a config file, like .gitignore, that keeps node_modules searchable but tells the agent to never read or send .env, *.pem, id_*, .aws and .ssh. It has sat open since August.
Engineers in the thread argue the feature is impossible to do safely: if the model can run shell, a stray 'rg foo' that matches an .env line uploads the secret anyway. The fix they keep naming is not a blocklist but a sandbox.
The one-line feature that won't ship
On August 28, 2025, a user named mkusaka opened issue #2847 on the OpenAI Codex repo: give the agent a way to exclude sensitive files. The ask is specific — a .codexignore-style config, working at both repo and global level, that would "keep node_modules/ searchable for implementation checks, but never read or send .env, .env., .pem, id_, .aws/, .ssh/"*. It points back to an earlier issue (#205) that was closed when Codex was rewritten in Rust, and the protection never came back. The labels are Enhancement and Sandbox. The issue is still open.
Why a blocklist can't hold a secret
The sharpest objection in the thread is that the feature, as drawn, is unenforceable the moment the agent has a shell.
"What if the model runs 'rg foo', and one of those files contains the string 'foo'? It uploads the tool output, which includes the file contents… the only solution is to make it so the codex process is unable to access those files, hence using a container, or unix permissions, or deleting the files." — a commenter with \~9.7k karma who walked through the failure case
That is the recurring split: people want the rule to cover bash, not just the read/edit tools, while still letting make touch the same files — which can't be done perfectly. A second voice put the danger of shipping it anyway in one line.
".agentsignore is NOT a security tool… using it to prevent exposure of secrets would be a BIG mistake. There's simply no way to guarantee that an agent will ignore things in the ignore file. And even a harness-enforced restriction would still be in-process, which a rogue agent could trivially compromise." — the author of the yoloai sandbox
The maintainer of a Linux sandbox project framed it as a fundamental layering error: the runtime shouldn't be asked to police itself.
"Files that codex and any other coding agent has access to, should be opt-in NOT opt-out. I think codex is not the right layer to solve this if you want a sane(one-click) UX." — an engineer who built an internal sandboxing terminal around Claude and Codex
The fix people actually use
Underneath the objections sits a quieter consensus on what works today: chmod the files out of reach, run inside a container with nothing sensitive mounted, or stop putting secrets in repo files at all. One commenter argued the whole .env convention is the real bug — keys should ride through a proxy like ssh-agent instead of sitting on disk where a tool call can scoop them. The thread is dense with shipping alternatives — apptainer, bind mounts, devcontainers, macOS sandbox wrappers — which is the uncomfortable read for OpenAI: the demand for #2847 is loud because the safe answer requires leaving the agent's own UI, and a one-click toggle that looked like protection would be worse than the gap it fills.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
EU revives twice-rejected Chat Control in a closed-door trilogue, on a Monday morning
Parliament rejected the message-scanning mandate in March. By June 29 it was back on the schedule for a private three-way negotiation that never has to face a public vote.