Configurable file exclusion patterns for sensitive files

Description

While Codex CLI respects platform sandboxing and provides security through network isolation, there's currently no documented way to configure file exclusion patterns to prevent the AI assistant from accessing sensitive files. This is a critical security feature needed for production codebases where files like .env, API configuration files, and credential files must be protected from AI access.

We need the ability to define custom ignore patterns at both global level (applying to all projects) and project level (specific to individual projects), similar to how other AI coding assistants handle this.

Problem

When using Codex CLI, the AI assistant can potentially read and access sensitive files such as:

• .env files containing API keys and secrets
• Configuration files with database credentials
• Private keys, certificates, and .pem files
• Firebase configuration files
• AWS/cloud provider credential files
• Any project-specific sensitive files

While the sandboxing provides network isolation, there's no way to prevent the AI from reading these files in the first place, which poses security risks:

1. Accidental exposure of secrets in AI responses
2. Potential for sensitive data to be included in API requests
3. Compliance issues in enterprise environments
4. Developer anxiety when using AI tools with production codebases

Proposed Solution

Add support for configurable ignore patterns at both global and project levels, following the patterns established by other AI coding tools:

1. Global ignore patterns in ~/.codex/config.json:

{
  "ignorePatterns": [
    "**/.env",
    "**/.env.*",
    "**/secrets/**",
    "**/credentials.json",
    "**/*.key",
    "**/*.pem",
    "**/firebase.js",
    "**/firebase-config.*"
  ]
}

2. Project-level ignore patterns in .codex/config.json:

{
  "ignorePatterns": [
    ".env.local",
    "config/database.yml",
    "app/secrets/**"
  ]
}

3. Support for a .codexignore file (recommended):

Similar to .gitignore, allow users to create a .codexignore file that lists patterns for files that Codex CLI should never access:

# Secrets and environment files
.env
.env.*
secrets/

# API keys and credentials
**/apikeys/**
firebase.js
google-services.json
GoogleService-Info.plist

# Private keys and certificates
*.key
*.pem
*.p12
*.pfx

# Database files
*.sqlite
*.db

# Configuration with sensitive data
config/database.yml
config/secrets.yml

Implementation Examples from Other Tools

Claude Code:

# Command-line configuration
claude config add ignorePatterns .env
claude config add -g ignorePatterns "**/.env"

# Settings file approach
{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Edit(**/.env)"
    ]
  }
}

Cursor:

Cursor supports a .cursorignore file and UI-based configuration where users can specify files and folders to exclude from AI context.

Gemini CLI:

Currently respects .gitignore patterns but lacks additional configuration options (similar feature request needed).

Expected Behavior

1. Complete inaccessibility: Files matching ignore patterns should be completely invisible to the AI
2. Clear feedback: When the AI attempts to access an ignored file, it should receive a clear message like "Access denied: file matches ignore pattern"
3. Pattern precedence: Global patterns → project patterns → .codexignore patterns
4. Tool coverage: Patterns should apply to all file operations (read, write, list, search)
5. Performance: Pattern matching should be efficient even with many patterns

Use Cases

1. Enterprise compliance: Meet security requirements for AI tool usage in regulated industries
2. Open source development: Safely use AI assistance without exposing private deployment configs
3. Multi-tenant projects: Protect customer-specific configuration files
4. Personal projects: Keep API keys and personal data secure
5. Team collaboration: Share AI configuration without exposing team-specific secrets

Technical Considerations

• Patterns should follow .gitignore syntax for familiarity
• Consider supporting both allow and deny lists for maximum flexibility
• Integration with existing sandboxing should be seamless
• Pattern evaluation should happen before any file access attempt
• Consider caching pattern compilation for performance

Related to Existing Features

This enhancement would complement the existing security model:

• Works alongside the network-disabled sandboxing
• Adds defense-in-depth to the existing permission system
• Natural extension of the approval modes (suggest/auto-edit/full-auto)

Backwards Compatibility

This feature should be fully backwards compatible:

• Default behavior remains unchanged if no patterns are configured
• Existing workflows continue to work
• Opt-in configuration ensures no breaking changes

References

• Related to issue #85 (Add ability to hide sensitive files from agent)
• Similar features in Claude Code, Cursor, and other AI coding assistants
• Builds on the existing security model documented in the README