Back to Research

OpenAI Codex Sensitive Files Issue

Codex Workshop research on issue #2847, agent ignore files, and safer Codex CLI workflows around secrets.

Summer Foliage, landscape painting by George Inness (1883).
Rogier MullerJuly 3, 202610 min read

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, OpenAI’s coding agent 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, Anthropic’s coding agent, 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. The trap is assuming .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

Common questions

  • Did issue #2847 mean Codex was leaking secrets?

    No. Issue #2847 was a feature request for an explicit mechanism to exclude sensitive files from agent reads and model context. The risk it describes is indirect exposure: a tool command such as search or test output can include secret values even when the agent did not intentionally open a secret file.

  • Is a .codexignore file enough security?

    No. A .codexignore-style file would be useful as a deterministic hint or harness rule, but it should not be your only protection for secrets. The citable caveat is simple: if the process can read the file, a tool call may still surface its contents unless enforcement happens below that read.

  • How should I think about codex cli vs claude code for secrets?

    Think about the workspace boundary first, then the product. Codex CLI and Claude Code both benefit from project instruction files, but secrets need operating-system permissions, containers, or a copied workspace with sensitive paths removed. The useful comparison is not “which model behaves better,” but “which harness cannot read the file.”

  • Can AGENTS.md solve this in OpenAI Codex?

    AGENTS.md can reduce mistakes, but it cannot replace access control. Use it to document repo rules, out-of-scope paths, verification commands, and what the agent should do when it needs a secret. The hard boundary still needs to be enforced by file permissions, container mounts, or a secret-free workspace.

  • Should MCP servers be disabled until this is fixed?

    No, but start narrow. MCP can be valuable for GitHub issues, docs, and internal tools, yet each server expands what the agent can see. A good first boundary is read-only access to one system needed for the task, with no broad private document store or production credential access.

Best ways to use this research

  • Best for: Codex users who run the CLI in real repositories and want a safer habit before asking an agent to inspect code.
  • Best first artifact: A short AGENTS.md boundary note plus a copied workspace that excludes secrets before codex starts.
  • Best comparison angle: Treat Codex CLI versus Claude Code as a harness and workflow comparison, not a claim that one assistant can be trusted with secrets.
  • Best verification loop: Ask for small diffs, run scoped tests, inspect command output, and only then move the patch back into the original repo.

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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Related training topics

Related research

Ready to start?

Transform how your team builds software.

Get in touch