How can sensitive files remain uncompromised when using Codex CLI?

[ilmeskio]

Summary

During testing with Codex CLI, I noticed an important nuance regarding how ignored files are handled:

• When I reference files directly using @ (e.g. @config/settings.py), files listed in .gitignore are not included in the model context — which is great.
• However, when using commands like rg, cat, or other workspace-wide searches, those same ignored files can still be read locally and their contents may appear in Codex responses.

This raises some uncertainty about how to safely handle sensitive information (like .env files, credentials, or local configs) that might be present in the workspace but should never be exposed to the model or remote context.

Questions

1. How can users guarantee that sensitive files are never read or transmitted — even indirectly (e.g. via rg, cat, search, or summarization commands)?
2. Does Codex CLI perform any local filtering before sending file contents to the model (for instance, checking .gitignore or .env patterns)?
3. Is there a recommended way to mark or isolate sensitive files so they’re always out of scope for Codex — regardless of the command used?

Why this matters

In practice, developers often have secrets or credentials stored in .env, .json, or config files within the same repository.
Even if those files are ignored by Git, it’s unclear whether Codex might still read them locally when using tools like rg or global context searches.

It would be extremely helpful to have:

• an official explanation of how the CLI handles ignored files under different command types, and
• concrete guidance (or a recommended pattern) to ensure that sensitive data is never at risk of being sent to the model.

Thanks for clarifying this — it’s key for safely using Codex in real development environments.

[ilmeskio]

At least on macOS we could leverage the sanbox adding some filter up: this will totally hide files from the sandbox reaching the best level of security.

https://github.com/openai/codex/blob/main/codex-rs/core/src/seatbelt.rs

(deny file-read* (regex "\\.env$"))
(deny file-write* (regex "\\.env$"))

I don't know how claude code is operating on this but it seems that can give this sort of security: https://www.devproblems.com/securing-claude-code-protecting-your-sensitive-files-like-env/

IMHO having a protection at sandbox level gives the best guarantee.

[ilmeskio]

🧱 macOS — sandbox-exec profile

Even though sandbox-exec is deprecated, it still works as a temporary layer of protection:

(version 1)
(allow default)
(deny file-read*  (regex "\.env$"))
(deny file-write* (regex "\.env$"))

Run Codex inside it:

sandbox-exec -f deny-env.sb codex run

This blocks all read/write access to .env files anywhere on the system.

---

🐧 Linux — Landlock or Bubblewrap

On Linux, you can reach similar isolation using either Landlock (kernel >= 5.13) or Bubblewrap.

Option 1 – Landlock (allowlist model):
Allow read/write only to specific directories, leaving .env outside the allowed paths:

landrun   --ro /usr --ro /lib --ro "$PWD/src"   --rw "$PWD/.codex-cache"   --cwd "$PWD" --   codex run

Since .env is not whitelisted, it cannot be accessed by Codex or its subprocesses.

Option 2 – Bubblewrap (mask .env):
Mount an empty tmpfs over .env to make it invisible:

bwrap --ro-bind / / --tmpfs $PWD/.env --chdir "$PWD" codex run

[ilmeskio]

I didnt test the linux solutions yet

[ilmeskio]

related issues:

• Repository- and global-level .codexignore to explicitly exclude sensitive files #2847
• Feature Request: Add configurable file exclusion patterns for sensitive files (global & project level) #1397

[andreiblt1304]

Great thread, my guy!