Automations ignore configured approval_policy = "on-request" and run with effective approval = never

Open 💬 2 comments Opened Jun 11, 2026 by jon-carey-krowgroup

What version of the Codex App are you using (From “About Codex” dialog)?

26.608.12217

What subscription do you have?

Enterprise

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex desktop automations appear to ignore configured approval-policy settings and run with an effective no-escalation policy.

In my setup, both the global config and the project config specify approval_policy = "on-request". The project config also sets sandbox_mode = "read-only", the project is trusted, and the app configuration UI shows Approval policy: On request and Sandbox settings: Read only.

However, when I run an automation in this project, the transcript says the current execution policy is effectively never, so the automation cannot request escalation when a read-only command is blocked by sandbox or network restrictions.

This breaks monitoring automations that need to run read-only inspection commands such as doctl and retry them with approval if necessary.

What steps can reproduce the bug?

Configure the global Codex config with:

approval_policy = "on-request"

Configure the project .codex/config.toml with:

approval_policy = "on-request"
sandbox_mode = "read-only"

Ensure the project is trusted.

In Codex desktop settings, confirm the project shows:

Approval policy: On request
Sandbox settings: Read only

Create or run an automation in that project.
Have the automation run a command that may need escalation after a sandbox/network failure.
Observe the automation transcript.

In my case, the transcript reports that the execution policy is effectively never, and escalation is unavailable.

What is the expected behavior?

Automations should inherit the effective default/project configuration.

For this project, I expect the automation to run with:

approval_policy = "on-request"
sandbox_mode = "read-only"

If a command fails because of sandbox or network restrictions, the automation should be able to request approval for an escalated retry instead of behaving as though approval is disabled.

Additional information

Relevant config and environment details:

Global config:

approval_policy = "on-request"

Project config:

approval_policy = "on-request"
sandbox_mode = "read-only"

Project trust entry exists for:

[projects."/Users/<user.name>/<project>"]
trust_level = "trusted"

Additional observations:

The automation tooltip says: Automations run with your default sandbox settings.
I restarted the app and the behavior did not change.
Local environment settings appear unrelated; they control setup scripts and actions, not approval policy.
The UI and config both indicate on-request, but the automation runtime still behaves as never.

My current hypothesis is that automations are either:

not inheriting the same config layers as interactive sessions
using a hidden automation-specific policy source
or hitting a desktop app bug in approval-policy inheritance

View original on GitHub ↗

2 Comments

rpelevin · 2 months ago

This looks like approval-policy inheritance drift rather than only an automation sandbox failure.

The invariant I would test is that an automation run produces an effective execution-policy record before its first command is evaluated. That record should include:

global approval policy;
project approval policy;
project trust state;
UI-displayed sandbox and approval mode;
any automation-specific override;
final effective approval policy and sandbox mode;
reason/source for any downgrade.

If the UI and config both say on-request, an automation should not silently enter a no-escalation policy. It should either inherit on-request, or surface an explicit automation policy source that says escalation is disabled.

The regression case is narrow:

global config sets approval_policy = "on-request";
project config sets approval_policy = "on-request" and read-only sandbox;
app UI displays on-request/read-only for the trusted project;
automation attempts a command that fails due to sandbox or network boundary;
transcript shows an escalation request can be created, or shows a visible explicit policy source explaining why it cannot.

The bad state is the silent downgrade: policy appears approval-capable at the config/UI layers, but the automation transcript can only fail as if approval is unavailable. That leaves operators unable to distinguish a real denial from an inheritance/config drift bug.

jon-carey-krowgroup · 2 months ago

Additional clarification based on follow-up analysis:

This may be more specifically an approval-policy inheritance / effective-policy drift issue, not only a sandbox escalation failure.

What seems to be missing is a visible effective execution-policy record for automation runs before the first command is evaluated. For debugging, it would help if automation runs surfaced:

global approval policy
project approval policy
project trust state
UI-displayed approval/sandbox settings
any automation-specific override
final effective approval policy and sandbox mode
the reason/source for any downgrade

In this case, the visible config/UI layers indicate approval_policy = "on-request" for a trusted project, but the automation transcript behaves as though approval is unavailable.

The narrow regression case appears to be:

global config sets approval_policy = "on-request"
project config sets approval_policy = "on-request" and sandbox_mode = "read-only"
app UI displays On request / Read only for the trusted project
automation attempts a command that hits a sandbox or network boundary
transcript should either:

create an escalation request, or
explicitly show the policy source that disabled escalation

The bad state is a silent downgrade: config and UI appear approval-capable, but the automation transcript only fails as if approval is unavailable.

That makes it difficult to distinguish:

a legitimate policy denial
an automation-specific override
a config inheritance bug