Codex permission/config behavior is becoming a serious reliability problem for automation workflows

[aifirstd3v]

I want to raise a broader product reliability concern around Codex permissions, approvals, MCP tools, and config compatibility across Codex CLI and Codex App.

For users running Codex as a real automation/development environment, the current permission model is becoming too fragile and unpredictable. The same setup can behave differently depending on whether the session is launched from Codex CLI, Codex App, a remote connection, an embedded app CLI, or a project-local .codex/config.toml.

The most frustrating part is that “Full access” does not consistently mean what users reasonably expect it to mean in an automation context. Even with settings such as:

• approval_policy = "never"
• sandbox_mode = "danger-full-access"
• trusted project configuration
• MCP server approval modes set to approve

Codex can still interrupt workflows with permission prompts, MCP approval dialogs, or ARC/safety-related confirmations. This makes hands-off workflows unreliable, especially for remote development, browser automation, Playwright/Chrome DevTools MCP usage, codebase analysis, and long-running agentic tasks.

There also appears to be a structural inconsistency in how permissions are enforced compared to other coding agents. For example, Claude generally continues to respect custom deny rules defined under its permissions system even when operating in a full-access mode. In contrast, Codex running with danger-full-access can behave as though certain custom permission restrictions are bypassed or inconsistently enforced. If this is intentional, it should be clearly documented. If not, it represents a significant reliability and security concern because users cannot confidently predict whether their custom permission policies will actually be honored during execution.

There is also too much ambiguity between the older sandbox_mode configuration and the newer default_permissions / [permissions] profile system. Both appear in the official config surface, but mixing them can break sessions with unclear errors. In practice, users are forced to debug config schema interactions instead of doing actual work.

The configuration system itself has become a major reliability concern. Config files are critical because even a small schema or setting change introduced during a version upgrade can prevent Codex connections or sessions from starting altogether. When this happens, users are often forced into a repetitive cycle of manually comparing configuration files against updated schemas, identifying which settings have changed, and repeatedly testing configurations until they find the incompatibility. This is especially frustrating because configuration breakages are often discovered only after an update has already disrupted a previously working workflow.

The recent 0.141.x / Codex App update path made this worse for some users. A working setup can suddenly fail after an update, or start asking for permissions repeatedly, without a clear migration warning, compatibility check, or actionable error message. That is not acceptable for a tool that developers increasingly rely on as part of their daily workflow.

Another concern is that Codex Changes and release notes often do not clearly explain the practical impact of configuration, permission, or schema-related updates. When behavior changes, users need explicit information about what was modified, which existing configurations may be affected, what migration steps are required, and what risks or compatibility concerns should be considered before upgrading. Too often, these impacts must be discovered through trial and error rather than through official documentation.

What I would like to see:

1. A clearly documented “full automation / trusted local development” mode that actually suppresses routine command and trusted MCP approval prompts while still respecting explicitly configured deny rules.
2. A deterministic explanation of which layer is asking for approval: shell command, sandbox, MCP, app connector, ARC/safety, or remote executor.
3. A built-in config validator/migrator that detects invalid combinations such as sandbox_mode mixed with default_permissions, and proactively warns users about deprecated or incompatible settings before startup failures occur.
4. Clear compatibility notes when Codex App embeds a different CLI version than the user’s PATH codex.
5. A documented way to trust selected MCP servers/tools while keeping sensitive tools, such as GitHub write operations, prompt-gated.
6. Clear documentation describing how custom permission rules interact with danger-full-access, including whether deny rules are guaranteed to be enforced and under what circumstances they may be overridden.
7. Stronger changelog and Codex Changes documentation that clearly describes configuration schema changes, migration requirements, compatibility risks, permission behavior changes, remote execution impacts, and any actions users should take before upgrading.

The current behavior wastes real developer time. It is not just a small UX annoyance. When an update changes permission behavior or breaks config compatibility, it interrupts running workflows, remote sessions, and automation pipelines. In the worst cases, a single configuration change can prevent Codex from launching or connecting at all until users manually investigate schema differences and rebuild their configuration.

Codex is powerful, but this permission/config layer needs to become boring, explicit, testable, and stable. Developers should not have to reverse-engineer which approval system is blocking them after every update, nor should they have to manually audit configuration schemas after every release just to keep previously working environments operational. Just as importantly, users should be able to trust that explicitly defined permission policies will be enforced consistently, regardless of whether Codex is running in a restricted mode or in danger-full-access.