🧱 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

The key distinction is:

• .gitignore is a discovery/context convenience.
• The sandbox / permissions profile is the security boundary.

If a file is readable by Codex or by a subprocess Codex starts, then its contents can indirectly reach the model through stdout/stderr, summaries, test failures, cat, rg --no-ignore, etc. So I would not treat .gitignore as sufficient for secrets. To guarantee a file cannot be exposed, make it unreadable to the Codex sandbox.

A practical setup is to put a custom permission profile in ~/.codex/config.toml:

default_permissions = "safe-workspace"
approval_policy = "on-request"

[permissions.safe-workspace.filesystem]
glob_scan_max_depth = 4
":minimal" = "read"

# Optional, but many build/test tools need temp space.
":tmpdir" = "write"
":slash_tmp" = "write"

# Common home-level secrets.
"~/.ssh" = "deny"
"~/.aws/credentials" = "deny"
"~/.azure" = "deny"
"~/.config/gcloud" = "deny"
"~/.netrc" = "deny"

[permissions.safe-workspace.filesystem.":workspace_roots"]
"." = "write"

# Repo-local secrets.
".env" = "deny"
".env.*" = "deny"
"**/.env" = "deny"
"**/.env.*" = "deny"
"**/*.pem" = "deny"
"**/*.key" = "deny"
"**/id_rsa" = "deny"
"**/id_ed25519" = "deny"
"**/.npmrc" = "deny"
"**/.pypirc" = "deny"
"**/.netrc" = "deny"
"**/secrets" = "deny"
"**/secrets/**" = "deny"

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false
exclude = [
  "AWS_*",
  "AZURE_*",
  "GITHUB_*",
  "OPENAI_API_KEY",
  "*TOKEN*",
  "*SECRET*",
  "*PASSWORD*",
  "*PASS*",
]

Then start a new Codex session and verify the boundary:

cat .env
rg --hidden --no-ignore "TOKEN|SECRET|PASSWORD|OPENAI_API_KEY" .

Those should fail or be unable to read the denied files.

For organizations, the stronger version is to enforce deny-read requirements centrally so users cannot weaken them locally, for example:

[permissions.filesystem]
deny_read = [
  "/**/.env",
  "/**/.env.*",
  "~/.ssh",
  "~/.aws/credentials",
  "~/.azure",
  "~/.config/gcloud",
  "~/.netrc",
]

A few important caveats:

• Do not use danger-full-access if you want this protection. Full access means you are intentionally removing the filesystem boundary.
• Do not rely on output redaction as the primary defense. Redaction can only ever be best-effort; the reliable fix is preventing reads in the first place.
• Keep real secrets outside the repo when possible. Use .env.example or fake local config files for Codex-visible development context.
• If you configure external MCP/filesystem tools, make sure they have their own access limits too. The Codex sandbox protects Codex-managed local commands, not every possible external service you might connect.

So the short answer is: ignored files are not enough. Use sandbox permission profiles or managed deny-read requirements for secrets. That is the right layer to prevent cat, rg, test logs, or accidental summarization from exposing sensitive files.