Allow deny-list (blocklist) rules on top of Full Access / danger-full-access mode

What variant of Codex are you using?

App (Codex Desktop)

What feature would you like to see?

Currently, permission profiles can extends = ":workspace" or extends = ":read-only" and add filesystem deny rules (e.g. denying **/*.env). However, profiles cannot extend :danger-full-access, and Codex rejects unknown parents / inheritance cycles.

This means "Full Access" is strictly all-or-nothing: once enabled, there is no way to carve out excluded paths (e.g. ~/.ssh, ~/.aws, other project directories, credential stores) that should stay off-limits even when the agent otherwise has broad local access.

For users who want an agent to move fast across a large workspace or system without constant approval prompts, but still want hard guarantees that certain sensitive directories are never touched, there's currently no supported configuration path.

Proposed solution

Allow a permission profile to extend :danger-full-access (or introduce an equivalent broad-access base profile) while still permitting filesystem deny overrides, e.g.:

[permissions.broad-with-exclusions]
description = "Broad local access with sensitive paths excluded"
extends = ":danger-full-access"

[permissions.broad-with-exclusions.filesystem]
"~/.ssh/**" = "deny"
"~/.aws/**" = "deny"
"~/Library/Keychains/**" = "deny"

This would give a middle ground between workspace-write (too restrictive for cross-project work) and danger-full-access (no exclusions possible at all).

Additional information

Alternatives considered:

• Manually crafting a custom profile that extends :workspace with many additional writable roots — but this loses the "broad access by default" ergonomics and requires maintaining an allowlist rather than a blocklist.
• Using OS-level file permissions to block access — works but is heavy-handed, affects all processes (not just Codex), and isn't portable across the different sandbox backends (Seatbelt/bubblewrap/Windows).

Other coding agents support this "broad access + explicit deny list" pattern. Claude Code, for example, lets you define allow/deny rules in settings.json that take precedence regardless of the active mode — a deny rule always wins over a broader allow rule and blocks access even when a permissive rule would otherwise permit it. This lets users grant broad access while still hard-excluding sensitive paths like .env files or SSH keys. Reference: https://code.claude.com/docs/en/permissions

A similar mechanism for danger-full-access in Codex would close this gap.