A way to exclude sensitive files
Navigation Menu
Toggle navigation
[](https://github.com/)
Appearance settings
* Platform
* AI CODE CREATION
- GitHub Copilot Write better code with AI
- GitHub Copilot app Direct agents from issue to merge
- MCP Registry New Integrate external tools
* DEVELOPER WORKFLOWS
- Actions Automate any workflow
- Codespaces Instant dev environments
- Code Review Manage code changes
* APPLICATION SECURITY
- GitHub Advanced Security Find and fix vulnerabilities
- Code security Secure your code as you build
- Secret protection Stop leaks before they start
* EXPLORE
- Blog
* Solutions
* BY COMPANY SIZE
- Startups
* BY USE CASE
- DevOps
- CI/CD
* BY INDUSTRY
* Resources
* EXPLORE BY TOPIC
- AI
- DevOps
- Security
* EXPLORE BY TYPE
* SUPPORT & SERVICES
- Partners
* Open Source
* COMMUNITY
- GitHub Sponsors Fund open source developers
* PROGRAMS
* REPOSITORIES
- Topics
- Trending
* Enterprise
* ENTERPRISE SOLUTIONS
- Enterprise platform AI-powered developer platform
* AVAILABLE ADD-ONS
- GitHub Advanced Security Enterprise-grade security features
- Copilot for Business Enterprise-grade AI features
- Premium Support Enterprise-grade 24/7 support
- Pricing
Search or jump to...
Search code, repositories, users, issues, pull requests...
Search
Clear
Provide feedback
We read every piece of feedback, and take your input very seriously.
- [x] Include my email address so I can be contacted
Cancel Submit feedback
Saved searches
Use saved searches to filter your results more quickly
Name
Query
To see all available qualifiers, see our documentation.
Cancel Create saved search
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Uh oh!
There was an error while loading. Please reload this page.
- NotificationsYou must be signed in to change notification settings
- Code
- Actions
- Insights
Additional navigation options
- Code
- Issues
- Actions
- Insights
A way to exclude sensitive files#2847
Copy link
Copy link
Closed
Closed
A way to exclude sensitive files#2847
Copy link
Labels
enhancement New feature or requestNew feature or requestsandbox Issues related to permissions or sandboxingIssues related to permissions or sandboxing
Description
opened on Aug 28, 2025
Contributor
Issue body actions
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.
👍React with 👍456 vacavaca, gluix20, chaudepark, TDogVoid, DebugDruid510 and 451 more
Activity
added
enhancement New feature or requestNew feature or request
mentioned this on Aug 29, 2025
- Include dotfiles in @-file search suggestions #2846
torson commented on Aug 30, 2025
More actions
`.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 .
👍React with 👍71 mkusaka, yusufrahadika, AntonioMeireles, chaudepark, paulschwenn and 66 more
tcgumus commented on Sep 1, 2025
More actions
so there isn't anyway to prevent sensitive data to reach codex right now?
👍React with 👍14 codeblooded, iliyian, tjbortz1s, adama357, 3f6a and 9 more
vacavaca commented on Sep 2, 2025
More actions
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.
👍React with 👍41 mrmallam, mkusaka, jdustinlewis, tycomo, nils-hoglund and 36 more
dunkel000 commented on Sep 3, 2025
More actions
+1. It is very important for some corporations and projects to ensure that agents do not indiscriminately ingest everything, including sensitive data or keys.
👍React with 👍24 nils-hoglund, ferrouswheel, pelegm, chan-jui-huang, mrasyadc and 19 more
booyoi commented on Sep 22, 2025
More actions
need it too
👍React with 👍8 nils-hoglund, pelegm, mrasyadc, prettymuchbryce, codeblooded and 3 more
numlock1052 commented on Sep 24, 2025
More actions
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
👍React with 👍24 petyniak, sealad886, ferrouswheel, nils-hoglund, Vistyy and 19 more
chan-jui-huang commented on Sep 30, 2025
More actions
Please implement it! It is very important for security!
👍React with 👍29 shybyte, EvanOman, thebodevelopment, kostya-fr, Vistyy and 24 more
mentioned this on Oct 5, 2025
prettymuchbryce commented on Oct 8, 2025
More actions
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)" ]`.
👍React with 👍30 will-path, chan-jui-huang, jgador, AppleNectar, NdQuan127 and 25 more
ilmeskio commented on Oct 23, 2025
More actions
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).
undefinedscheme (version 1) (allow default) (deny file-read* (regex "\.env$")) (deny file-write* (regex "\.env$")) undefined
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).
👍React with 👍19 prettymuchbryce, codeblooded, andreiblt, spenweb, phpws and 14 more
mentioned this on Oct 23, 2025
- Configurable file exclusion patterns for sensitive files #1397
codeblooded commented on Oct 27, 2025
Last edited by codeblooded
More actions
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.
👍React with 👍3 spenweb, Keramis and Grawave
jbalonso commented on Oct 29, 2025
More actions
Does this issue qualify as a security concern (my opinion: it should) for the purposes of welcoming a contribution as per the contributor guidelines?
👍React with 👍13 steveepreston, silver-ben, Keramis, jabrown93, HuzaifaTP and 8 more👀React with 👀3 ilmeskio, silver-ben and LockedThread
122 remaining items
Load more
mentioned this on Jun 29, 2026
- 🤖 AI 资讯日报 - 2026-06-29 itoe558/daily-ai-news#30
mentioned this on Jun 29, 2026
- 📊 AI CLI 工具社区动态日报 2026-06-29 zx0828/big_model_radar#193
mentioned this on Jun 29, 2026
- HackerNews Top 10 @2026-06-29 jacky1234/blogPages#1087
mentioned this on Jun 29, 2026
- 📰 Hacker News AI 社区动态日报 2026-06-29 96loveslife/big_model_radar#77
nothingnesses commented on Jun 29, 2026
Last edited by nothingnesses
More actions
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.
👀React with 👀1 DLakomy
mentioned this in 4 issues on Jun 29, 2026
- 🤖 AI 日报 · 2026-06-29 worldguigui/github-claw#64
- 📰 AI 科技日报 — 2026-06-29 liyupi/github-claw#119
- 📰 AI 科技日报 — 2026-06-29 Wndall/VibeCodingProgram#43
- 📰 AI 科技日报 — 2026-06-29 feIce/my-github-claw#40
mentioned this on Jun 29, 2026
- KI Daily – 2026-06-29 kronprinzmagma/ki-news-aggregator#98
bolinfest commented on Jun 29, 2026
Collaborator
More actions
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).
❤️React with ❤️6 garogarabed12, mkusaka, Frulfump, marcom, johan456789 and 1 more
silver-ben commented on Jun 29, 2026
Last edited by silver-ben
More actions
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" ```
etraut-openai commented on Jun 29, 2026
Collaborator
More actions
I'm going to close out this feature request. As @bolinfestmentioned 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.
closed this as completedon Jun 29, 2026
mentioned this on Jun 30, 2026
- Journal Workflow - Week of 2026-07-04 beijaflor/gen-ai-journal#153
Sign up for free**to join this conversation on GitHub.** Already have an account? Sign in to comment
Metadata
Metadata
Assignees
No one assigned
Labels
enhancement New feature or requestNew feature or requestsandbox Issues related to permissions or sandboxingIssues related to permissions or sandboxing
Type
No type
Fields
No fields configured for issues without a type.
Projects
No projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Participants
+61
Issue actions
Footer
[](https://github.com/) © 2026 GitHub,Inc.
Footer navigation
- Terms
- Privacy
- Security
- Status
- Docs
- Contact
- Manage cookies
- Do not share my personal information
You can’t perform that action at this time.