Feature request: local pre-submit DLP/redaction layer for secrets before prompts are sent upstream

Feature request: local pre-submit DLP/redaction layer for secrets before prompts are sent upstream

Summary

Codex CLI should provide a local pre-submit DLP/redaction layer that detects and blocks or redacts sensitive information before any prompt, interactive TUI input, command text, file snippet, diff, terminal output, or attached context is sent to OpenAI/Codex servers.

This should happen locally, before network transmission.

Problem

Users can accidentally paste passwords, API keys, bearer tokens, private keys, database URLs, cookies, session tokens, .env contents, or other sensitive material into Codex CLI.

Today, project instructions such as AGENTS.md can tell the agent not to repeat, commit, or display secrets, but they do not provide a true pre-network interception layer. Once a user pastes a secret into the Codex prompt/TUI, the secret may already be included in the request payload before the model has any opportunity to follow redaction instructions.

This creates a class of accidental data-loss events where the user’s intention is not to share the secret, but the CLI has no built-in local guardrail to stop it.

Desired behaviour

Codex CLI should support a local secret-protection mode, for example:

codex --redact-secrets
codex --block-secrets
codex --dlp=redact
codex --dlp=block

or a config option:

[privacy]
local_secret_filter = "block" # off | warn | redact | block
scan_user_input = true
scan_file_context = true
scan_terminal_output = true
scan_diff_context = true

Before sending any content upstream, Codex should locally scan the outbound payload.

If sensitive material is detected, the CLI should either:

1. Block submission and warn the user.
2. Redact the sensitive value and ask the user to confirm.
3. Replace the value with a typed placeholder such as:

• <REDACTED_API_KEY>
• <REDACTED_PASSWORD>
• <REDACTED_PRIVATE_KEY>
• <REDACTED_DATABASE_URL>
• <REDACTED_BEARER_TOKEN>

Sensitive information to detect

The local scanner should detect common patterns including:

• passwords
• API keys
• bearer tokens
• OAuth tokens
• refresh tokens
• JWTs
• session cookies
• private keys
• SSH keys
• .env values
• service account JSON
• database URLs
• GitHub PATs
• OpenAI-style sk-... keys
• AWS access key IDs / secrets
• GCP / Azure credentials
• Stripe keys
• webhook signing secrets
• high-entropy credential-like strings

Important security property

This must happen before the request is sent to any server.

The goal is not merely to instruct the model not to reveal secrets. The goal is to prevent accidental secret transmission in the first place.

Example scenario

A user opens Codex CLI and accidentally pastes:

Fix my app. My DATABASE_URL is postgres://user:password@example.com/db

Expected behaviour in block mode:

Possible secret detected: DATABASE_URL
Codex did not send this prompt.
Replace the secret with an environment variable reference, e.g. $DATABASE_URL.

Expected behaviour in redact mode:

Fix my app. My DATABASE_URL is <REDACTED_DATABASE_URL>

Then Codex asks:

Sensitive value redacted locally. Send sanitized prompt? [y/N]

Suggested implementation

A local outbound-payload sanitizer could run immediately before request construction/transmission.

Possible stages:

1. Deterministic regex-based scanner for known token formats.
2. Entropy-based detection for unknown credential-like values.
3. Structured file-aware scanning for .env, JSON credentials, YAML secrets, npm/pypi config, Docker config, cloud credentials, etc.
4. Optional user-configurable allowlist/denylist.
5. Optional integration with existing secret-scanning engines such as Gitleaks-style pattern definitions.
6. A final confirmation UI showing a diff between original and sanitized prompt.

UX proposal

Modes:

• off: current behaviour.
• warn: warn user but allow manual override.
• redact: locally redact and ask confirmation.
• block: refuse to send until secret-like content is removed.

Recommended default:

warn

Recommended for high-security users:

block

Why this matters

Codex CLI is often used inside real development environments where secrets may be nearby in .env files, shell history, terminal output, logs, package-manager config, cloud config, and pasted debugging context.

A local pre-submit DLP layer would reduce accidental credential exposure and make Codex safer for professional software engineering workflows.

Related but insufficient mitigations

• AGENTS.md can instruct the agent not to reveal or commit secrets, but it cannot prevent the initial user input from being sent.
• .gitignore prevents committing secret files, but not pasting secrets into prompts.
• GitHub secret scanning helps after code reaches GitHub, but does not protect the prompt itself.
• Users can build wrappers, but interactive TUI input still needs first-class support inside Codex CLI.

Acceptance criteria

• Codex CLI can scan interactive TUI input locally before network submission.
• Codex CLI can scan non-interactive prompt arguments locally before network submission.
• Codex CLI can scan automatically included context before network submission.
• Detected secrets are never transmitted in block mode.
• Detected secrets are replaced before transmission in redact mode.
• The user can review what was redacted.
• The feature is configurable globally and per-project.
• The scanner avoids printing the detected secret in warning messages.
• Tests cover common secret formats and false-positive handling.

Possible config example

[privacy]
local_secret_filter = "block"
scan_user_input = true
scan_file_context = true
scan_terminal_output = true
scan_diffs = true
redaction_placeholder = "<REDACTED>"
show_redaction_diff = true

Closing note

This would make Codex CLI significantly safer for developers who use it with real repositories, real logs, real .env files, MCP tools, local shells, and cloud credentials.