Add Configurable Path Ignore Support Across Codex CLI, Exec, and TUI

Resolved 💬 2 comments Opened Oct 27, 2025 by vjain419 Closed Nov 15, 2025

What feature would you like to see?

I’d like Codex to support a first-class “ignore paths” mechanism so sensitive or noisy areas of a repo stay off-limits no matter how the agent runs.

Core requirements:

  • Configurable ignores: allow glob patterns (e.g. vendor/**, *.secrets) in config.toml, CLI overrides, or AGENTS.md. These should apply even in --dangerously-bypass-approvals-and-sandbox/yolo mode.
  • if dir includes the .codex_ignore/.ai_ignore/.agent_ignore(any name you find better) then don't scan/read/edit it. This allow enterprise to deploy certain package with those file so user don't need to do any configuration.
  • End-to-end enforcement: the exclusions must block the agent from reading files, staging edits, applying patches, running commands, or generating plans that target the ignored paths. Attempts should fail with a clear explanation for the user.
  • UI alignment: remove ignored paths from fuzzy file search results, change previews, and any other UI surfaces so the agent never suggests touching them.
  • Telemetry/feedback: whenever an action is blocked, surface a concise message and log entry so users understand which ignore rule triggered.
  • Tests/docs: add coverage that proves the ignores are respected across CLI, exec, and TUI flows, and document how to configure them (plus interactions with .gitignore, --cd, etc.). The goal is to give teams a safe escape hatch before

committing to fine-grained per-command approvals: point Codex at a repo, specify the off-limits directories once, and know the automation can’t touch them.

Why this matters (enterprise security & legal)
This feature is especially valuable for enterprise security, compliance, and legal teams: sensitive assets can be quarantined so Codex never reads or copies them into logs or model prompts; deterministic guardrails simplify audits and policy
enforcement; legal can impose directory-level restrictions to preserve licensing/export constraints; security gains confidence that automation can’t exfiltrate or alter protected files. Encoding these policies once and relying on Codex to
enforce them everywhere would unlock broader, safer adoption in regulated environments.

Additional information

thread ID 019a2002-6f32-7390-9458-ccdd4bdec481 - used /feedback with some ideas.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗