Retiring approval_policy="untrusted" without deprecation weakens the execution-approval boundary

Summary

Codex 0.149.0 retired approval_policy = "untrusted" in #39630 and now refuses to start when an existing configuration contains it:

``text
Error loading configuration: approval_policy = "untrusted" is no longer supported; remove this setting
``

Simply removing the setting is not a neutral migration. For a project configured with trust_level = "trusted", the effective default becomes on-request, which provides a materially weaker command-
execution approval boundary.

This is a breaking security-policy change shipped without a deprecation period, without an equivalent replacement, without migration guidance in the prominent release notes, and while the official
documentation still describes untrusted as valid and recommends it for this use case.

## Previous security boundary

With:

```toml
default_permissions = "readonly-net"
approval_policy = "untrusted"
approvals_reviewer = "user"

[permissions.readonly-net]
extends = ":read-only"

[permissions.readonly-net.network]
enabled = true

[permissions.readonly-net.network.domains]
"*" = "allow"

[projects."/path/to/project"]
trust_level = "trusted"
```

the policy provided two separate controls:

1. The permission profile constrained filesystem and network access.
2. The untrusted approval policy required approval before executing commands outside the known-safe command set.

This meant repository scripts, build tools, dependency hooks, arbitrary executables, and commands with external execution paths could not run merely because they fit within the OS sandbox.

## Boundary degradation after removal

The error tells users to remove the setting. In a trusted project, doing that selects on-request.

Under on-request, commands that fit inside the active permission profile may run without approval. approvals_reviewer = "user" does not restore the previous behavior; it only controls who reviews
actions already classified as requiring approval.

In the example above, read-only filesystem enforcement remains, but arbitrary code can potentially execute with:

• read access granted by the permission profile;
• unrestricted outbound network access; and
• no approval prompt merely because the command is not known-safe.

That is a meaningful security-boundary degradation. Read-only protection prevents modification, but it does not prevent sensitive-data disclosure. Repository-controlled code or a compromised
dependency may be able to read accessible credentials or configuration and send them over the network.

Before:

``text
Known-safe command?
├─ Yes: run within the sandbox
└─ No: require user approval
``

After following the instructed migration:

``text
Can the command run within the sandbox?
├─ Yes: it may run automatically
└─ No: request additional permission or fail
``

These are not equivalent security postures.

Marking every project trust_level = "untrusted" is also not an equivalent migration. According to #39630, untrusted projects now request approval for every command unless an exec-policy rule allows
it. That is stricter than the retired policy, must be configured per project, and changes the meaning of project trust to compensate for the removal of a global approval policy.

## No reasonable deprecation process

PR #39630 was merged on August 20, 2026 and included directly in 0.149.0.

Retiring a public security control in a single release by turning previously valid configuration into a startup failure—without first warning users, documenting a migration, or providing a
behaviorally equivalent replacement—is not a reasonable deprecation strategy.

For a security-sensitive setting, the startup error is especially problematic because its only remediation is:

> remove this setting

It does not warn that removal may weaken the execution-approval boundary. It does not explain that trusted projects will fall back to on-request. It does not point to an equivalent supported
configuration because no equivalent appears to exist.

This retirement process makes no sense from either a compatibility or a security perspective. A normal process would include:

1. A deprecation warning for at least one release.
2. Documentation of the precise behavioral difference.
3. An equivalent supported migration path.
4. Automatic migration where possible.
5. A prominent breaking-change notice before enforcement.

## Missing from the prominent release notes

The change is present only as an entry deep in the generated full changelog:

• #39630 — “Retire the untrusted approval policy”

It is absent from the curated New Features, Bug Fixes, and Documentation sections of the 0.149.0 release notes.

A change that invalidates existing configuration and alters a security boundary should be called out prominently as a breaking change, not left as one line among the generated commit list.

## Official documentation still says it is valid

At the time of filing, current official documentation still treats untrusted as supported:

• The configuration reference lists approval_policy values including untrusted:

https://developers.openai.com/codex/config-reference/

• “Agent approvals & security” documents --ask-for-approval untrusted, describes its known-safe behavior, and provides an explicit config.toml example:

https://learn.chatgpt.com/docs/agent-approvals-security

The documentation therefore directs users to configure a value that current Codex rejects at startup.

## Reproduction

1. Install a Codex version that supports approval_policy = "untrusted".
2. Add this to ~/.codex/config.toml:

``toml
approval_policy = "untrusted"
``

1. Upgrade to Codex CLI 0.149.0.
2. Run:

``sh
codex resume
``

1. Observe:

``text
Error loading configuration: approval_policy = "untrusted" is no longer supported; remove this setting
``

## Requested resolution

Please consider:

1. Restore untrusted temporarily and emit a deprecation warning.
2. Provide a supported replacement that preserves its actual semantics:

• run a limited known-safe command set automatically;
• require user approval for other command execution;
• keep this independent of filesystem/network sandbox restrictions.

1. Add an explicit migration warning explaining that removing the setting selects on-request for trusted projects and weakens the approval boundary.
2. Document the change prominently under “Breaking changes” in the 0.149.0 release.
3. Correct all official documentation before removing support.
4. Establish and document a deprecation policy for security-relevant configuration.

## References

• PR: https://github.com/openai/codex/pull/39630
• Commit: https://github.com/openai/codex/commit/942af8447b1d1addc81fb3c3135293497d479a06
• Release: https://github.com/openai/codex/releases/tag/rust-v0.149.0

The ChatGPT desktop app (the Codex-based one) is choking on an old config value.
Your config.toml still has:
tomlapproval_policy = "untrusted"
That value was retired. The app now rejects it on startup and refuses to launch.
Fix

Fully quit the ChatGPT app (don’t just close the window — use Quit or Task Manager if needed).
Open File Explorer and go to:text%USERPROFILE%\.codex
Open config.toml in Notepad (or any text editor).
Find the line approval_policy = "untrusted" and either:
Delete the entire line, or
Change it to approval_policy = "on-request" (the current default equivalent).

Save the file.
Restart ChatGPT.