OpenAI Codex Sensitive Files Issue

By Rogier Muller07.03.26
OpenAI Codex Sensitive Files Issue

Codex CLI and Claude Code differ less on model magic than on harness boundaries: neither should be treated as a secrets boundary unless the operating system, container, or workspace layout enforces it. The GitHub issue people described as “A way to exclude sensitive files issue still open for OpenAI Codex” matters because it asked for a deterministic way to stop an agent from reading or sending files like .env, private keys, and cloud credentials.

Codex CLI is a local terminal coding agent from OpenAI that can inspect and edit a repository from your shell. The Codex CLI vs Claude Code comparison gets practical here: the question is not which assistant is smarter, but which workflow makes accidental secret exposure harder.

Read issue #2847 as a boundary request

The anchor is openai/codex issue #2847, titled “A way to exclude sensitive files.” It requested repo-local and global ignore rules, with examples like .env, .env.*, *.pem, id_*, .aws/**, and .ssh/**.

The important detail is the requested shape. The author did not ask for another paragraph in project instructions. They asked for a deterministic, shareable mechanism that the Codex harness could enforce before file contents reached the model.

As of the July 2026 repository snapshot used for this article, the issue is marked closed, after opening in August 2025 and gathering a long discussion. That status does not make the underlying problem disappear. It mostly proves developers care about a crisp line between “agent, please ignore this” and “agent cannot read this.”

OpenAI Codex family, also has a few surfaces that make this request understandable. The repository describes Codex CLI as a lightweight coding agent that runs in your terminal, mostly written in Rust, licensed Apache-2.0, and widely watched by developers. A terminal agent is close to the filesystem by design. That closeness is the superpower and the footgun.

Do not confuse ignore rules with security

An agent ignore file is a routing hint that tells a coding agent which paths are out of scope; it is not a security boundary unless the harness enforces it before reads, search output, and tool results reach the model.

That distinction is the whole story. A model does not need to open .env directly to see sensitive material. It might run rg DATABASE_URL, inspect a test failure, or summarize a command output that happens to include a token.

The thread around issue #2847 split along this line. Some developers wanted a .codexignore-style standard because it would be easy to share across repos. Others argued that a soft ignore file could create false confidence, because real protection comes from file permissions, separate users, containers, or workspaces that simply do not contain the files.

Both sides have a point. A harness-enforced denylist would improve everyday ergonomics and reduce accidental reads. It still would not replace secret hygiene, because the safest secret is the one that is not mounted into the agent’s workspace.

A concrete repo example makes this less abstract. Suppose a Node service keeps .env.local beside package.json, and the agent runs rg stripe to find where payments are wired. If .env.local contains STRIPE_SECRET_KEY=..., the command output can leak the value even if the agent never intended to inspect secrets.

Compare Codex and Claude Code on this boundary

Claude Code uses a different product surface, including CLAUDE.md project memory. Codex CLI uses OpenAI’s terminal flow and supports repository instructions through AGENTS.md. Those files are useful, but they sit above the hard boundary that matters for secrets.

Criteria Codex CLI Claude Code
Local repo context Runs as a terminal coding agent on your computer; it can work directly in the checked-out repo you start it from. Also works against local project context through its coding-agent workflow.
Durable project instructions Uses AGENTS.md for repository guidance and conventions. Nested instruction files can scope behavior to parts of a repo. Commonly uses CLAUDE.md as persistent project memory and instructions.
Sensitive file lesson Issue #2847 shows Codex users want deterministic repo/global excludes, not only prose instructions. The same lesson applies: memory files can tell an agent not to read secrets, but permissions and workspace shape are the stronger control.
Best fit for this problem Good when you want an OpenAI Codex CLI workflow with explicit repo rules, verification commands, and MCP boundaries. Good when your project already centers Claude Code memory and you want its native instruction model.

Verdict: Codex CLI wins when your workflow is already built around OpenAI Codex, AGENTS.md, and terminal verification loops; Claude Code wins when your repo conventions already live in Claude’s project memory. For secrets, neither wins by documentation alone. The safer answer in any codex vs Claude Code comparison is to remove or block sensitive files before the agent starts.

Run Codex like the ignore file is advisory

Until the agent boundary is the boundary you want, treat ignore rules and AGENTS.md as helpful instructions, not protection. The practical Codex CLI vs Claude Code takeaway is simple: make the workspace safe first, then let the agent reason inside it.

A small AGENTS.md note is still worth writing because it reduces pointless reads and token waste:

# AGENTS.md

Do not inspect or summarize local secret files.
Treat these paths as out of scope: .env, .env.*, *.pem, id_*, .aws/**, .ssh/**.
If a task appears to require a secret, stop and ask for a redacted fixture or documented interface instead.

Before proposing changes, run:
- git diff --stat
- git diff -- . ':!*.pem' ':!.env*'
- npm test -- --runInBand

That file is not enough. Pair it with a workspace copy that excludes secrets before you run codex:

mkdir -p /tmp/codex-safe-work
rsync -a \
  --exclude '.env' \
  --exclude '.env.*' \
  --exclude '*.pem' \
  --exclude '.aws/' \
  --exclude '.ssh/' \
  ./ /tmp/codex-safe-work/

cd /tmp/codex-safe-work
codex

This pattern is boring, which is why it works. Don't assume .gitignore or a prompt sentence protects you. .gitignore controls Git tracking, not what a terminal agent or search command can read.

If your Codex workflow uses MCP, keep the same rule. MCP is an integration protocol that can connect an agent to systems like GitHub, docs, issue trackers, or databases. Start with read-only scopes, avoid broad document indexes that include secrets, and give the agent a narrow server before you give it a powerful one. For more repo instruction examples, see Codex Agent Rules for Real Repos and the broader CLI workflows topic.

Copy this before-you-run checklist

Use this as a quick fit/not-fit table before starting a Codex agent in a real repo.

Check Fit to run Codex now Not fit yet
Workspace contents The working directory is a copied or containerized workspace with .env, keys, cloud config, and personal SSH material absent. Secrets are present but “the agent was told not to read them.”
File permissions The user running Codex cannot read sensitive host paths. Codex runs as your normal user with access to your home directory secrets.
Repo instructions AGENTS.md names out-of-scope paths and tells the agent to ask for redacted fixtures. Secret handling is hidden in tribal knowledge or a one-off chat prompt.
Search commands Verification uses scoped commands such as git diff, targeted tests, and excludes for known secret patterns. The first step is broad rg or cat over the whole tree.
MCP access MCP servers are read-only and scoped to the task. The agent can browse broad private stores or production systems by default.
Review loop You inspect diffs and command output before copying results elsewhere. You accept generated summaries without checking whether tool output included sensitive values.

A clean handoff receipt can be tiny:

Safe workspace prepared: yes
Secrets mounted: no
Instruction file checked: AGENTS.md
MCP scope: read-only GitHub issues only
Verification commands run: npm test, git diff --stat
Human review required before merge: yes

Further reading

Next step

Before your next Codex run, make a secret-free workspace and add the AGENTS.md boundary note above. Then run the agent only inside that workspace and review the diff like any other code change.