A way to exclude sensitive files

.agentignore would be better - more tool agnostic, now that AGENTS.md has been adopted by multiple tools including Codex. Cline uses .clineignore, Cursor uses .cursorignore and .cursorban . There's a similar feature request for Cline : https://github.com/cline/cline/discussions/5887 .

so there isn't anyway to prevent sensitive data to reach codex right now?

Based on my tests, there seems to be no way to prevent Codex from uploading all files into OpenAI, regardless of .gitignore or AGENTS.md. If Codex decides to use rg or grep and finds some relevant content in a file, it will be uploaded.

+1 for adding this feature, it is important not only for protecting confidential data, but also for preventing Codex from uploading tons of irrelevant stuff, such as caches, node_modules, types, etc.

+1. It is very important for some corporations and projects to ensure that agents do not indiscriminately ingest everything, including sensitive data or keys.

need it too

Hello, I suggest using the same approach as Google to exclude certain folders from the context .aiexclude. So, if we switch from gemini-cli to codex or another CLI AI, it will simplify the developer's life.

https://cloud.google.com/gemini/docs/codeassist/create-aiexclude-file

Please implement it! It is very important for security!

This feels like table stakes for any security-minded organization that doesn't want Codex to indiscriminately upload keys, secrets, environment variables, passwords, etc to OpenAI servers where they are potentially stored permanently. Claude code makes this trivial via settings.local.json with "deny": [ "Read(.secret-dir)" ].

I totally agree with this issue. Right now, even if gitignored files cannot be referenced with @, the agent can still read sensitive files both through the Read tool and via shell commands (rg, cat, etc.).

This means that the only way to achieve a proper level of security is to enable protection at the sandbox level, completely removing those files from the Codex execution context.

On macOS, I tested a solution leveraging sandbox-exec (which Codex internally uses). I’ve expanded on this in a discussion: [GitHub Discussion #5523](https://github.com/openai/codex/discussions/5523).

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

This works correctly — running sandbox-exec -f deny-env.sb codex prevents Codex from reading the contents of .env files. However, it’s a somewhat hacky solution and should ideally be handled natively within Codex itself.

After discussing with ChatGPT (somewhat meta 😄), it suggested an alternative using Landlock on Linux, based on an allowlist model. I need to investigate it further, but Landlock seems the right long-term mechanism, as it is already used internally by Codex.

Implementing such protections is crucial to ensure a safe development environment.

Another issue also discusses this problem and contains additional proposals: [GitHub Issue #1397](https://github.com/openai/codex/issues/1397).

Considering Claude Code has a 5 seat minimum for teams, which my company doesn't meet yet... we'd move to Codex for Teams in a heartbeat with this feature for the business license. We're holding back (and considering Gemini code assist), because Codex lacks a deterministic permissions system.

Does this issue qualify as a security concern (my opinion: it should) for the purposes of welcoming a contribution as per the contributor guidelines?

+1, this is such a basic aspect, I'm surprised it hasn't been implemented yet!

Please add this feature, its a basic security and performance issue. I don't want Codex reading everything in my codebase and sometimes, like to keep PRDs and Plan files in my repo for future reference that are outdated and confuse the model, which as of now I have no way of restricting.

This is the first thing should implemented before the release.
⚠️ Ignoring this issue will increase current distrust toward openai.

• a million for .codexignore support

This is the first thing should implemented before the release. ⚠️ Ignoring this issue will increase distrust toward openai.

100% agreed. I installed codex in my IDE this week assuming this would be a feature, and I have now uninstalled it. The fact that it wasn't included in the first release has very much increased my distrust towards openai.

Claude Code and Gemini have both implemented this feature, so why isn't Codex considering it? I really want this feature.

was planning to try out codex and found this, can't use it without this, very surprised to find out it doesn't have it, also doesn't give much trust in that it won't creep out into other paths that it shouldn't be allowed to access.

Any ETA for this feature?

⚠️ This is a Critical Data Leakage.
They are ignoring this first must-have feature.

Is there a timeline or any kind of information when this feature request is getting implemented. You can't take that seriously. How are you supposed to use Codex in customer projects?!

Commenting to bump this again, deterministic file exclusions is absolutely crucial for Codex. I would venture to say nearly every piece of modern software has some sort of sensitive env variables, secret keys, etc that need to stay prviate and cannot be ingested by LLMs.

@jalapenopeppers OpenAi needs those envs and keys

We need this too pls

Since OpenAI doesn't seem to want to implement this, I built a jail for it instead: https://gist.github.com/mnpenner/137ccdccf7619dfc403c53ddd1b626e6

This exposes your project dir to codex but hides most of the rest of your filesystem and makes it read-only so it can't wreak too much havoc.

I want to mask over private files inside the project dir too but I haven't figured out how to do that yet without mounting a ton of empty files over everything. If anyone has suggestions for that, please LMK in the gist comments.

An absolute must-have for enterprise users.

In my company, we just reverted the recommendation of using codex cli because of missing this feature! It is the major blocker for enterprise users.

@dandanwei We have switched to Qwen CLI
Openai is trolling users

This really should be something easy to setup as in gemini cli: https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/sandbox.md#enable-sandboxing-in-order-of-precedence

export GEMINI_SANDBOX=podman
gemini -p "deep research space based datacenters"

It's 2026 and this is has been totally ignored more than half a year. It was the first feature Claude, Gemini and others implemented. The irony that this has been ignored for so long is a meme. How is this not the #1 priority for the codex team? To be blunt, this is the biggest negative around codex use. Not only the security issues, but the sheer waste of context unnecessarily, not to mention the continual snooping that happens by the agent and directory creeping. Please support a .agentsignore or .codexignore structure.

@etraut-openai Write an answer about this security issue, or mention someone to answer

Codex acts as a Trojan: Codex reads files outside working directory without my permission

highly desired: this feature or one similar to https://github.com/openai/codex/issues/5237 (controlling read access to only desired paths)

It wouldn't be bad to have this feature, but you need to realize it wouldn't be completely enforceable. If a LLM decides he needs to see that secret for some reason, it will find a way to do it (cat, python, etc). Maybe with tools you previously whitelisted and deemed innocuous.

Not true. If you jail the entire process, you can restrict what files it has access to, even if it calls subprocesses to try to skirt around.

It really concerns me that there's no movement on this. It's not an unreasonable request given how the tool operates. How about start with respecting the already established .aiexclude with an optional .codexignore for Codex specific overrides?

Confirming that Codex can read files outside the working directory. There's no hard stop that prevents it from doing so.
This is useless:
--cd app/src/you-should-only-be-here-plus \
--add-dir app/src/modules/distance

It can literally go to the pictures on my Desktop and make fun of me.

I implemented configurable sensitive-path(&pattern) exclusion + exclusion logging in my fork, xCodex (xcodex).

xCodex only (WIP): https://github.com/Eriz1818/xCodex
Docs: https://github.com/Eriz1818/xCodex/blob/main/docs/xcodex/ignore-files.md

What it adds:

• Repo-local ignore files (gitignore-style patterns) to exclude paths from AI-assisted workflows.
• Exclusion logging to CODEX_HOME/log/exclusion-redactions.jsonl with reasons like ignored_path, secret_pattern,

etc.

Enable logging:
[exclusion]
exclusion = true # by default true, only uses L1 + L3
paranoid = true # Turns L2 + L4 on
log_redactions = "summary" # off|summary|raw
(many more toggles, whitelists, blacklists...)

Exclusion model:

• Layer 1: Input guards / path matching (deny-read for structured tools)
• Layer 2: Output sanitization
• Layer 3: Send firewall
• Layer 4: Request interceptor

Paranoid mode:

• paranoid_mode = true enables Layer 2 + Layer 4 by default (layers can still be overridden individually).

Notes:

• Best-effort at the AI layer (not an OS boundary); shell commands and external MCP servers can still read whatever the OS

allows. But, L4 will block it if pattern is matched.

Why is this ignored? My .env.local was read by the new Codex App

Some guy tried to address this security issue in the https://github.com/openai/codex/pull/10847 PR, but an openai employee closed it as unsolicited code contributions. Current issue history and that PR closing act, sounds as there is benefits for openai in keeping this security issue up.

@steveepreston, we're working on this feature. It's complicated to get right. There are many challenges that are not obvious at first glance.

If an open source project refuses to accept any pull requests except from it's own employees, is it really an open source project?

To me and our company this is a MAJOR issue.

Sometimes codex decides it must dig in personal files to best address an issue (logs containing personally identifiable information, files containing API keys and other critical data, etc.), which can often go unnoticed. It's very unpredictable.

No offence, but OpenAI may say "we don't share your chats with third parties" but we all know what happens when companies hoard data for a while; it often ends up leaked online eventually. Or provided to other companies "lawfully".

Say there is an SSH auth error, Codex might decide to proactively dig into ~/.ssh to see if there's anything wrong there, ingesting critical files in the process.

As bad as it is in my experience, gemini-cli at least seems to have much more stringent sandboxing and controls, including multiple restrictive profiles on macOS and an optional cross-platform containerization approach with Docker.

Pull #10847 (or a similar implementation) seems like a very good first step with few if any downsides.

Yep, we understand this is an important feature. We generally prioritize features based on upvotes from the community. A month ago, this feature was somewhere around 15th in the priority queue. We've been steadily delivering new features based on that prioritization approach. This feature is now near the front of the queue, and we're actively working on it. It will be implemented as a series of PRs. Here's an example of one that was merged in the last day. As part of this effort, we're also looking at ways to simplify our sandbox configuration mechanism, which is admittedly more complicated and confusing than it needs to be.

@fortinmike, it's not as simple as merging a PR from a contributor. We need to ensure that any changes are correct, don't introduce new security vulnerabilities, work across all supported platforms and surfaces (including third-party clients that build upon the Codex harness), don't break existing or in-flight features, and are maintainable and supportable by the team. For a feature like this, design work is required ahead of any implementation. The project is open source, so if you want to fork and apply PR #10847 as a short-term workaround while you're waiting for us to deliver this feature, you have that as an option.

@etraut-openai I can understand that an external PR might not be the best implementation long term. Maybe it was the way it was dismissed (without any acknowledgment of the importance of what it was trying to achieve) that made some people uneasy. In any case I'm glad this issue is being worked on! Thanks for the insight into what is going on on this front.

@etraut-openai

Thanks for answering.

we're working on this feature. It's complicated to get right. There are many challenges that are not obvious at first glance.

Based on this sentence, you should instantly stop the Releases. This is a CVE and you are easily saying it's in our Queue.
This behavior constitutes an insecure default that can expose confidential data to the model and any downstream logging or storage, effectively creating an information‑leak vulnerability. Classifying it as a CVE is appropriate because the flaw is reproducible, impacts confidentiality, and can be exploited simply by placing the CLI in a project that contains secret files.

Based on this sentence, you should instantly stop the Releases. This is a CVE and you are easily saying it's in our Queue. This behavior constitutes an insecure default that can expose confidential data to the model and any downstream logging or storage, effectively creating an information‑leak vulnerability. Classifying it as a CVE is appropriate because the flaw is reproducible, impacts confidentiality, and can be exploited simply by placing the CLI in a project that contains secret files.

Perhaps at this point we should go back and read the original request:

A mechanism to explicitly mark files/paths that the agent must not read or send to the model, at both repository and global levels (e.g., a repo-local .codexignore plus a global ignore file).

Currently if you have an item that should be kept secure, you have to remember not to put it in directories the model can read.

If this feature existed, then you _could_ put that item in a directory the model can read, as long as you remembered to mark that directory or item as excluded from the model.

So without the feature you have to remember something, whereas with the feature you have to remember something different.

There's no security issue here. This is a convenience feature. If you want security, don't expose your secure stuff to the model. If you really want security, don't put your secure stuff on the same machine as the model.

@rlundy

No, this isn’t just “convenience.” Automatically reading project files without a clear, enforced opt‑out creates a reproducible information‑leak vector. Classifying it as a CVE is appropriate because it impacts confidentiality, is exploitable by default, and requires no special conditions beyond placing the CLI in a repo with secrets. Fix the default (stop Releases) or require an explicit, safe opt‑in before any project files are processed.

Telling users “don’t put secrets on the same machine” isn’t a substitute for secure defaults, systems should prevent accidental leakage rather than rely on normal / risky developer workflows.

The risk goes beyond personal and business data leakage:

if the CLI can read project files it may expose SQL/SSH/API keys and credentials, enabling unauthorized queries, remote access, or destructive commands during debugging or automation.

The official line here is that this was not prioritized before because it is a feature request and hadn't so far gathered sufficient upvotes. But it was reported multiple times as a security issue:

https://github.com/openai/codex/issues/5237
https://github.com/openai/codex/issues/5203
https://github.com/openai/codex/issues/4410
https://github.com/openai/codex/issues/4152

And given they rejected this as a bug report, I filed an explicitly titled feature request https://github.com/openai/codex/issues/8396 which was also promptly (and correctly) shut down for being a duplicate of this.

I get that this is key infra for OpenAI. They could have just put in a big red notice in the README.md so that users _don't ever run this with internet access outside of an isolated container_, but they chose not to. To me the largest issue is that they declined to put a prominent README warning and/or show how to safely run within a container, which it wasn't that hard. This codex cli capability of reading anything everywhere is startling, unexpected, confusing given how much the default sandbox is prominently featured and shoved in your face in the default config every time that it attempts to execute a trivial command. Surely if this SANDBOX asks for permissions for ANYTHING AT ALL inside the repo, it won't be able to read EVERYTHING in my computer, right?

@Manouchehri Ironically this policy exists because of AI slop generated by codex. Otherwise this repo would end up like https://github.com/openclaw/openclaw/pulls with ~3,5k open PRs, which isn't any better tbh. But working on issues only because of upvotes is stupid because privacy and security are not always the most popular unless there's a shitstorm about it.

@santiago-afonso 4,482,387 installs on VSCode. I suspect the vast majority are unaware of this issue and might rethink their usage once they get to know of it.

@etraut-openai

Maybe i'm just under-thinking it but if it's tricky to implement something like excluding a file from all ops why not just allow a redaction list where you can define strings like an API key that get filtered from any newly added context. Like a .redations that's newline separated strings.

Where it might just replace the string with a bunch of X's. So it can cat, rg, ls etc but the results of those get a deterministic filter/replace before going into the agent's context.

This might actually be even more advantageous because it could "see" what you have in an env file like the key names but with the sensitive stuff redacted.

So it would know to do something like proces.env.SOME_KEY without ever seeing the value of the key.

so what it would see is something like:

SOME_KEY=XXXXXXXXXXXXX

FOO=XXXXXXXXXXX

BAR=XXXXXXXXX

@natorojo You never know how a LLM might respond to this. With access to tools, it could easily circumvent it by piping the output through base64 in order to accomplish its goal, whatever that might be.

@rkuemon so true like i said "under thinking it" crafty LLMs

I would welcome this being even a whitelist rather than blacklist, as two alternatives. As in "only allow reading those files"

+1 For this Critical Data Security Issue.

I am running the WSL use case - in VS code - I'm not sure if that is applicable to this repo or not.

I don't actually mind codex having unrestricted access to the linux box as that doesn't contain any important or secure files. However. Codex being able to read the contents of /mnt/c that aren't the project directory is a problem.

I would welcome this being even a whitelist rather than blacklist, as two alternatives. As in "only allow reading those files"

Agree. An explicit whitelist would be a lot safer.

Hello,

Seriously, this CVE has existed since August 28, 2025, and nothing has been done?? I used .aiignore from JetBrains, then the official Codex plugin, and I was absolutely shocked that Codex sent some explicitly disallowed files!

100% a CVE, 0% a feature, and the debate about it is a joke!!!

Those of you asserting that this is a CVE _(and who surely are not using the term "CVE" to mean "something I personally think should be a really high priority security issue")_, please be so kind as to include the CVE ID so we can look it up here:

https://www.cve.org

Here's an example of an actual Codex CVE from last year:

https://www.cve.org/CVERecord?id=CVE-2025-59532

https://github.com/openai/codex/issues/13778

I created now similar issue! It's a big issue, security issue!

I don’t understand why this issue is still unresolved. This should have been a day-one feature.

Will Codex follow symlinks, such that ./.env -> /path/outside/of/project/tree/.env would mean Codex sees the link target but doesn't read it?

I don’t understand why this issue is still unresolved. This should have been a day-one feature.

There is already a hard-coded respect_gitignore . It shouldn't be that hard for someone here to just have codex make it into a setting.

> I don’t understand why this issue is still unresolved. This should have been a day-one feature. There is already a hard-coded respect_gitignore . It shouldn't be that hard for someone here to just have codex make it into a setting.

Thank you for your reply. I may be missing something, but I can’t find this setting. Could you please point me to where it is or share the exact steps to locate it?

Exact results from a fresh APFS worktree: branch scratch/issue-2847-sensitive-files at 57c4c99; I re-ran cargo test -p codex-file-search gitignored_secret_files_are_omitted_from_search_results -- --nocapture plus COPYFILE_DISABLE=1 CARGO_TARGET_DIR=/tmp/codex-issue-2847-target cargo test -p codex-core gitignored -- --nocapture.

What I can support from current source/tests is narrower than ".gitignore already solves this":

• File search does have partial ignore behavior today. The fresh test gitignored_secret_files_are_omitted_from_search_results passed, which matches file-search defaulting respect_gitignore to true.
• Direct reads are different. The fresh codex-core test reads_gitignored_files_by_absolute_path passed, so read_file still reads a gitignored file when given its absolute path.
• Directory listing is different too. The fresh codex-core test lists_gitignored_entries passed, so list_dir still shows gitignored entries.
• Snapshot exclusions are a separate surface. ghost_snapshot is about large untracked files/dirs and undo/snapshot performance; it is not a general "never read / never send this path" policy.
• There is also at least one internal search path in core/src/rollout/list.rs that calls file search with respect_gitignore: false, so the existing behavior is not globally consistent even inside search-related code.

So the gap this issue is pointing at still looks real: Codex already has some ignore behavior, but not one unified exclusion contract applied consistently across search, direct reads, directory listing, and related context-building paths.

The product/design choice still looks open to me, but the behavior split above is concrete enough that I would not close this out as "already handled by the current hard-coded respect_gitignore behavior."

[Me at the next strategy meeting]: "There are really good AI tools out there now, where we don't have to upload every document in the web browser, but where we just point the AI at the right documents on our laptop and ask it to help us. It is really, really useful. If we continue to use ChatGPT and Codex, however, we essentially open our entire harddrive to OpenAI. There is no way of preventing this tool from uploading everything on our computer to the servers in Trump-land. If we move to Claude, there is an easy way to secure that the tool only sees what we want it to see."
[My boss]: "This is the easiest decision I have ever had to make."

A bit polemic and simplified, but in essence this is what will happen.

This should be considered a major security issue and an absolute priority, not just a feature request.

We have been told for decades to use .gitignore carefully to exclude sensitive files and now AI sends everything to a remote server...

@MagnusMG I can confidently say that they're losing money on Team/Enterprise sales exactly due to this issue. But if they're really just months away from AGI, then good on them, I guess, lmao.

I'm very surprised there isn't even just a simple blacklist/whitelist feature. It wouldn't solve everything, but at least give devs peace of mind that codex isn't accessing something that it shouldn't (and make it easier to hold it accountable if it does). Could also check for symlinks too.

+1 on this. This is one of the main security/config gaps I still feel in Codex.

Claude Code’s settings.json deny rules are a very good model here because they let you block reads of things like .env, *.pem, .ssh/, cloud creds, and other sensitive files with simple global patterns. It would be great for Codex to support something similar at both the global and repo level.

Even a first version with straightforward path/glob-based deny rules for file reads would be a big improvement.

They have been overhauling the permissions system, you can now use ~/.codex/config.toml to allow codex to only read from a whitelist of directories, here's what mine looks like. I'm on MacOS, the sandbox works a bit different on each OS.

approvals_reviewer = "user"
approval_policy = "on-request" # any of these restrictions can be bypassed with user approval. if you set this to "auto-review", these restrictions can be bypassed with reviewer agent approval
sandbox_mode = "workspace-write"
default_permissions = "workspace_only" # create a custom permissions profile

[permissions.workspace_only.filesystem]
":minimal" = "read" # minimal access required for codex to operate
"/Library/Developer/CommandLineTools" = "read" # required for git
":project_roots" = "write"
"/tmp" = "write"
"~/.cache/uv" = "write" # required for codex to use uv without approval

[permissions.workspace_only.network]
enabled = true
mode = "full"

[shell_environment_policy]
inherit = "core"
exclude = ["*_KEY", "*_TOKEN", "*_SECRET", "*_PASSWORD", "AWS_*"]

Note that ":project_roots" = "write" allows codex to modify your code workspace without asking approval, and if you set this to "read" you must also set all other "write" directories to "read"

You can also add project overrides in .codex/config.toml files.

Edit: They changed the system and this no longer works, see updated version here

Drafted an implementation on a fork at https://github.com/MukundaKatta/codex/tree/feat/sandbox-exclude-paths (since external PRs aren't accepted here).

Adds a [sandbox] config block with exclude_paths (gitignore-style, ! negations) and use_default_excludes covering common credential files. Patterns compile into FileSystemAccessMode::None entries on the resolved FileSystemSandboxPolicy, so list_dir, view_image, and the platform sandbox all enforce through one channel.

12 unit tests pass, cargo check clean. Happy to iterate or split.

This may be useful for people landing here from search: newer Codex config supports a partial workaround today via filesystem permission profiles in ~/.codex/config.toml.

It is not the same as a repo-local/team-shareable .codexignore, but it can enforce local deny-read rules for sensitive files before shell commands/tools can read them.

Example:

approval_policy = "untrusted"
sandbox_mode = "workspace-write"
default_permissions = "locked"

[permissions.locked.filesystem]
glob_scan_max_depth = 6

[permissions.locked.filesystem.":project_roots"]
"." = "write"
".env" = "none"
".env.*" = "none"
"**/.env" = "none"
"**/.env.*" = "none"
"**/*.pem" = "none"
"**/*.key" = "none"
"**/.aws/**" = "none"
"**/.ssh/**" = "none"
"**/id_rsa" = "none"
"**/id_ed25519" = "none"
"**/*secret*" = "none"
"**/*token*" = "none"

[sandbox_workspace_write]
network_access = false

Important TOML gotcha: approval_policy, sandbox_mode, and default_permissions need to be top-level keys, before [projects...] or other tables, otherwise Codex may not apply the profile.

I tested this locally with .env.test; direct reads via cat, rg, xxd, base64 -i, and Node fs.readFileSync() all failed with Operation not permitted / EPERM.

Docs:

• https://developers.openai.com/codex/config-reference
• https://developers.openai.com/codex/concepts/sandboxing

Caveats:

• This is user-local config, not a repo-local shared policy.
• It is a sandbox boundary, not a reason to store real production secrets in the repo.
• Users should not approve escalated commands intended to bypass the sandbox.

I set up my config-toml file as @ahalekelly suggested, but although this does restrict the sandbox permissions, I do not get any approval requests when codex tries to run commands outside the sandbox. Essentially it first tries to run commands inside the sandbox, and when that does not work it runs the same command "with escalation" and then it works. This means that codex still can read everything on my harddrive.

I have had codex search for any overriding config-files or pre-approved commands, without finding anything.

Weird. I see that same behavior now in CLI, but adding approvals_reviewer = "user" at the top seemed to fix it, maybe the default escalation reviewer changed to the AI auto-review, I'll update my code block above.

Also, the sandbox used to work in the Codex App as well, but now I see this behavior:

1. The sandbox no longer blocks any files at all, Codex can now read all files again without escalation.
2. When I add "/" = "none" it blocks everything including the workspace, same as before, more general rules override more specific rules. But now I see the same behavior you saw, it can override this by "escalating", but adding approvals_reviewer = "user" has no effect.

I see a bunch of recent permissions-related commits, maybe they changed something.

Edit: See updated version here

Hi, this makes codex unusable for us at the moment. We will switch to another tool.

Update: I extended the read-only preflight helper in trace-to-skill@0.1.77 so it can emit reviewable ignore-file candidates directly:

npx trace-to-skill@0.1.77 sensitive-audit . --format ignore --ignore-target codexignore --output .codexignore.generated

It can also target agentignore, aiexclude, or gitignore. The JSON report now includes ignoreFiles candidates for .agentignore, .codexignore, .aiexclude, and .gitignore.

Scope note: this is not a Codex sandbox or enforcement layer. It is filename/path-only, does not read file contents, does not follow symlink targets, and does not mutate the repo. It reports sensitive-looking paths such as .env*, .npmrc, .pypirc, .aws/**, .ssh/**, .kube/**, .docker/**, private keys/certs, mobile signing files, local databases, and secret manifests, then emits recommended exclude globs for maintainers to review.

Fresh registry smoke on a temp repo with .env, .aws/credentials, and local.sqlite produced a .codexignore candidate containing **/.env*, **/.aws/**, and **/*.{sqlite,sqlite3,db} without leaking secret values.

Release: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.77
Schema: https://github.com/grnbtqdbyx-create/trace-to-skill/blob/main/schemas/sensitive-audit-result.schema.json

A .codexignore helps the read path, but the sneakier leak is when an allowed command prints a secret to stdout (debug logs, ${VAR:+set} expansion) — ignore lists don't catch that. For that vector I've been using ironrun: injects the
secret into the child process, redacts the value out of stdout/stderr before it hits the model. Pairs with an ignore-list rather than replacing it.

www.github.com/generalized-labs/ironrun

This may be related to #25585.

#2847 seems to cover deterministic exclusion of sensitive files/paths before Codex reads or sends them to the model, e.g. .env, .pem, .ssh/, .aws/, etc.

#25585 extends the same privacy/security concern to the outbound prompt/request layer: scanning and blocking/redacting secrets locally before anything is transmitted upstream, including pasted prompts, terminal output, diffs, file snippets, and automatically gathered context.

It feels like these could be complementary parts of the same design:

• .codexignore / global ignore file = prevent known sensitive paths from being read or included
• local pre-submit DLP/redaction = catch secrets that still enter through prompts, logs, diffs, terminal output, or copied context

So even if sensitive files are excluded, a local outbound payload scanner would still be useful as a final safety layer before network submission.

Here's my latest config.toml if it's useful to anyone, now working in both Codex App and CLI in MacOS. I set it up so Codex has free read/write access to the project directory and /tmp, but can only read or write outside the project directory with approval from the auto-reviewer, instead of being able to read most directories without review.

model_reasoning_effort = "high"
plan_mode_reasoning_effort = "xhigh"

sandbox_mode = "workspace-write"
approval_policy = "on-request"
default_permissions = "workspace_sandbox" # create a custom permissions profile
approvals_reviewer = "auto_review" # set this to "user" to disable auto-review
analytics.enabled = false

[permissions.workspace_sandbox.filesystem]
":minimal" = "read" # minimal access required for codex to operate
"~/.agents" = "read" # agent skills
":tmpdir" = "write"     # $TMPDIR, usually /var/folders/.../T on macOS
":slash_tmp" = "write"  # /tmp
"/opt/homebrew" = "read" # allow running brew installed tools
"/Library/Developer/CommandLineTools/usr/bin" = "read" # allow running xcode installed tools
"~/.gitconfig" = "read" # required for git
"~/.config/git" = "read" # required for git
"~/.cache/uv" = "write" # required for uv
"~/.npm/_logs" = "write" # required for npm

[permissions.workspace_sandbox.filesystem.":workspace_roots"]
"." = "read"
"./**" = "write"
".git" = "write"

[permissions.workspace_sandbox.network]
enabled = true
mode = "full"

[shell_environment_policy]
inherit = "core"
exclude = ["*_KEY", "*_TOKEN", "*_SECRET", "*_PASSWORD", "AWS_*"]

[agents]
max_threads = 10

Hi everyone! I wanted to share something relevant here since this issue has been open a while.

The fragmentation is getting worse: .codexignore, .clineignore, .geminiignore, .cursorignore. All gitignore-syntax, all doing the same thing, none compatible. Switching agents means rewriting your ignore file.

I've been working on .agentignore as a vendor-neutral standard to solve this once: https://github.com/garogarabed12/agentignore

The RFC is at /RFC-0001.md in the repo.

I'd be happy to answer questions or discuss the spec.

@garogarabed12 that's a good proposal

My vote, however, goes to .agentsignore (plural agents, not singular agent), because:

• Consistency with AGENTS.md and .agents
• It matches what happens in practice (that is, multiple agents running in parallel)

.agentsignore is a good idea for a per-repo recommendation for what files the agent should not consider when it's working.

However, it MUST NOT be used as a security measure. That would be a huge mistake.

1. .agentsignore is per-repo, which means that the exclusions would be arbitrary per-repo, and your security becomes whatever the weakest link is. No one could know for certain which of your homedir files/dirs are sensitive.
2. It's in-process, which makes it insecure by definition.
3. A harness that checks for an .agentignore in your homedir would also be a bad idea. It leaves you having to continually audit your homedir files for anything sensitive. You WILL fall behind on it.
4. If you're storing secrets in your actual repo, you've already lost the battle.

If you want security, use a sandbox. Trying to secure the harness itself against exfiltration is a fool's errand.

Hello @PaulRBerg

That's a good suggestion, I've added a spec feedback template to the repo, would you mind opening an issue for this?

https://github.com/garogarabed12/agentignore/issues/new?template=spec-feedback.yml

Thanks.

Hi @kstenerud,

I agree with the security-boundary point, and the RFC explicitly covers this:

AgentIgnore is intended to reduce accidental exposure of files to AI agents. However, AgentIgnore is not a security boundary. It MUST NOT be relied upon as protection against malicious software, unauthorized users, compromised tools, or intentional data exfiltration. Sensitive files SHOULD still be protected using proper access control, encryption, secret management, and repository hygiene.

The goal is reducing accidental exposure during passive agent operations, not replacing sandboxing, permission models, or secret management.

I’ve tightened the wording/examples in the README to fully avoid presenting .agentignore as a security mechanism.

I can't see this working, the AI will happily bypass all this if it wants to. If you have an agent running, consider the environment compromised.

If you want security, use a sandbox.

True, and people should with a copy of their code honestly. It's very easy to get prompt fatigue.
Also, I think people should be getting in the habit of NOT hard-coding access to sensitive stuff into code.
Environmental Variables are one way, and with a sandbox that is doable too... I guess?

I'm honestly trying to find the best way to onion this out, but I think I'm in my own echo chamber. If you or anyone has suggestions to further improve that and not JUST rely on things like .agentsignore and treat it as part a layer of things so that they are less likely to lose code, have things exfiltrated, etc.

🙏🏻

I use codex inside membrane to allow ignoring specific files: https://github.com/noperator/membrane#configure

Config looks like this:

# `ignore` lists patterns matched against filenames or relative paths.
# Matching files and directories are shadowed with an empty placeholder
# inside the container; the agent can see they exist but cannot read
# their contents.
ignore:
  - secrets/
  - "*.pem"

# `readonly` lists patterns mounted into the container as read-only. Use
# this for things like .git (so the agent can read history but not
# rewrite it) or credential files that should be visible but not
# writable.
readonly:
  - config/

I've contributed to agent-box which allows you to bind-mount git repositories into containers that agents operate in, preventing the agents from accessing files that aren't bind-mounted. Your usual .gitignore can then be used to also ignore files within the repo to be bind-mounted, which prevents agents from accessing them at all, essentially working as a sandbox.

I also maintain agent-images which allows you to use Nix to reproducibly spin up OCI containers containing agents and any other tools you need and use these with agent-box.

I use both at the moment to work on some personal projects with agents, where I set up multiple separate git worktrees for the agents to work in, preventing them from accessing anything outside of the worktrees and from trampling over each other's work.

Sorry, I didn't realize this issue was open or I would have commented sooner, but we have had a solution for a number of months now, though we have been tweaking the config language here and there, which is why it is still tagged as "Beta" in the docs:

https://developers.openai.com/codex/permissions

You can use /permissions in the CLI to change the permission profile at runtime. We're still working to ensure things work equally smoothly in Codex App (which has more places where an agent loop gets created than the CLI, so the change is a bit more complex).

Okay i've done it like so:
added: repo-root/.codex/config.toml

default_permissions = "xxx-workspace"

[permissions.xxx-workspace.filesystem.":workspace_roots"]
"." = "write"
"out of context file here..." = "deny"

I'm going to close out this feature request. As @bolinfest mentioned above, we have a new feature in beta that implements this functionality. If you have follow-on bug reports or enhancement requests, please open a new issue.

For me it seems more preferred to have a more standardized approach like most .*ignore files that are more approachable and understood. Similar to how Codex adopted the .agents folder as a standard I would love to see a similar standard adopted here that is not Codex specific so it can also get wider adoption across other tools