The Missing Codex Ignore File and How to Work Around It

AI-powered developer agents are transforming how we write, refactor, and navigate codebases. By scanning entire repositories, these tools build a deep understanding of our application architecture. But this hunger for context introduces a massive security liability: the accidental ingestion and transmission of sensitive credentials.

This exact tension is at the heart of an open issue on the GitHub repository for OpenAI Codex. Opened on August 28, 2025, issue #2847 highlights a critical missing feature: a deterministic, shareable mechanism to explicitly mark files and paths that the agent must never read or send to the model.

Without a native ignore file, developers using these tools on real-world codebases are exposed to significant security risks. Fortunately, you do not have to wait for an official patch to secure your workflow.

The Context Leakage Problem

When an AI agent indexes a repository, it typically traverses the directory tree to gather context. While we want the agent to understand our helper functions and database schemas, we absolutely do not want it reading secrets.

The open GitHub issue outlines several high-risk targets that need to be excluded at both the repository and global levels:

• Environment configuration files (.env, .env.*)
• Private keys and certificates (.pem, id_)
• Cloud provider and SSH configurations (.aws/, .ssh/)

Ideally, a tool should support a configuration file, such as a repo-local .codexignore alongside a global user default. This would allow developers to keep directories like node_modules/ searchable for implementation checks while strictly blocking the agent from reading actual sensitive files.

This is not a new discussion. A previous issue, #205, surfaced similar concerns about preventing sensitive data transmission and excluding bloated files. That issue was closed in favor of a Rust-based implementation, codex-rs. However, as of late August 2025, a comparable ignore feature still does not exist in codex-rs. Relying on developer discipline or project documentation to avoid leaks is a recipe for an eventual security breach.

Why Standard Gitignores Fall Short

Many developers assume that a robust .gitignore file is enough to keep secrets safe. While some AI tools respect gitignore rules by default, this approach has two major flaws.

First, there are files you want Git to track but want to keep away from LLMs. For example, you might commit a large mock dataset or a third-party library to your repository, but sending those thousands of lines of code to an LLM API wastes tokens and slows down response times.

Second, the reverse is also true. You might have local configuration templates or development certificates that are ignored by Git but still sit in your local workspace. If an AI agent runs locally and scans your directory, it can easily scoop up those ignored local files and send them to an external API.

Practical Workarounds for Developers

Until a native, deterministic ignore mechanism is merged, you need to establish your own boundaries. Here are three practical strategies to protect your secrets today.

1. Shift to External Secret Management

The most effective way to keep secrets out of your AI's context is to remove them from your workspace entirely. Instead of storing API keys in flat .env files, use a dedicated secret manager like Doppler or HashiCorp Vault.

By injecting secrets directly into your application's runtime environment rather than saving them to disk, you ensure there are no physical files for an AI agent to accidentally read.

2. Use a Pre-Execution Sanitization Script

If you must keep sensitive files in your local workspace, you can use a simple shell wrapper to temporarily isolate them before running your AI agent.

This script moves sensitive files to a secure temporary directory outside your project root, executes the agent, and then restores the files when the process finishes:

#!/bin/bash
# safe-agent-run.sh

SAFE_DIR=$(mktemp -d -t codex-sandbox-XXXXXX)
SENSITIVE_FILES=(".env" ".env.local" "private.pem" ".aws" ".ssh")

# Move sensitive files out of the workspace
for item in "${SENSITIVE_FILES[@]}"; do
  if [ -e "$item" ]; then
    mv "$item" "$SAFE_DIR/"
  fi
done

# Run your AI agent command here
# e.g., codex-rs analyze .

# Restore the files to the workspace
for item in "${SENSITIVE_FILES[@]}"; do
  if [ -e "$SAFE_DIR/$item" ]; then
    mv "$SAFE_DIR/$item" ./
  fi
done

rm -rf "$SAFE_DIR"

3. Containerize Your Development Environment

For absolute isolation, run your AI agent inside a Docker container that only mounts safe directories. By explicitly defining the volume mounts, you guarantee the agent cannot access your global ~/.ssh or ~/.aws directories, even if it tries to traverse up the directory tree.

# docker-compose.yml
services:
  developer-agent:
    image: codex-agent-image
    volumes:
      # Mount only the source code, leaving local config files unmounted
      - ./src:/workspace/src
      - ./package.json:/workspace/package.json
    working_dir: /workspace

The Path Forward

Security in the era of AI-native development cannot rely on hope. The open issue in the Codex repository highlights a critical gap in how we build and interact with developer tools. Until deterministic, shareable ignore configurations become a standard feature across all AI developer agents, taking a proactive approach to workspace isolation is the only way to keep your credentials secure.