Automations ignore configured approval_policy = "on-request" and run with effective approval = never
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
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗