A way to exclude sensitive files

What feature would you like to see?

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).
Example: keep node_modules/ searchable for implementation checks, but never read or send .env, .env.*, .pem, id_, .aws/, .ssh/.
The configuration should be deterministic and shareable across the team/repo, and also support user defaults, rather than relying on project documentation or conventions.

Are you interested in implementing this feature?

Yes — I can contribute and tests.

Additional information

Related: #205. That issue surfaced two primary use cases: preventing sensitive data from being sent to the model and excluding large/irrelevant files. The issue was closed in favor of a Rust (codex-rs) implementation, but as of 2025-08-28 a comparable feature does not appear to exist in codex-rs. I’d like to restart the discussion and converge on a design.

.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 : cline/cline#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](#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](#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.

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

@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.

.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.
It's in-process, which makes it insecure by definition.
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.
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.

@PaulRBerg

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.

@kstenerud

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"

@bolinfest

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

@etraut-openai

@etraut-openai following up on the close: the beta exclusion feature doesn't yet enforce consistently across surfaces, so it may be worth flagging before this is considered fully implemented.

On Windows, with filesystem exclusions defined at the user level (%USERPROFILE%\.codex\config.toml, permission profile denying .env, secrets/**, credentials, etc.):

Codex CLI (0.145.0) honors them (agent correctly denied).
Codex App (26.721.31836) on Windows ignores the same config and still reads the excluded files (application.properties in my case).

Same config, machine, and user directory: enforced on one surface, not the other. There's currently no single user- or system-level location that enforces uniformly across both.

This is not an enhancement request nor a bug report because @bolinfest pointed out that in the Codex App work is still in progress so I think closing this request was a bit hasty. Should I file a new bug or will you reopen this one?

Navigation Menu

Repository navigation

A way to exclude sensitive files #2847

What feature would you like to see?

Are you interested in implementing this feature?

Additional information

74 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

A way to exclude sensitive files #2847

Description

What feature would you like to see?

Are you interested in implementing this feature?

Additional information

Activity

torson commented on Aug 30, 2025

tcgumus commented on Sep 1, 2025

vacavaca commented on Sep 2, 2025

dunkel000 commented on Sep 3, 2025

booyoi commented on Sep 22, 2025

numlock1052 commented on Sep 24, 2025

chan-jui-huang commented on Sep 30, 2025

prettymuchbryce commented on Oct 8, 2025

ilmeskio commented on Oct 23, 2025

codeblooded commented on Oct 27, 2025

jbalonso commented on Oct 29, 2025

fullofcaffeine commented on Nov 7, 2025

hasani114 commented on Nov 7, 2025

74 remaining items

garogarabed12 commented on Jun 27, 2026

PaulRBerg commented on Jun 28, 2026

kstenerud commented on Jun 28, 2026

garogarabed12 commented on Jun 28, 2026

garogarabed12 commented on Jun 28, 2026

EdwardBlair commented on Jun 28, 2026

arcticpinecone commented on Jun 28, 2026

noperator commented on Jun 28, 2026

nothingnesses commented on Jun 29, 2026

bolinfest commented on Jun 29, 2026

silver-ben commented on Jun 29, 2026

etraut-openai commented on Jun 29, 2026

kdawgwilk commented on Jul 1, 2026

asesovici commented on Jul 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions