codex - 💡(How to fix) Fix Windows Codex App still asks for approval even with approval_policy=never and danger-full-access

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

OpenAI.Codex 26.519.11010.0 OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

10.0.26200 Build 26200

What issue are you seeing?

I am using the standalone Windows Codex App, not the VSCode extension.

The Windows Codex App still asks for manual command approval even though the local rollout session metadata shows that the effective runtime context is already no-approval and full-access:

"approval_policy":"never"
"sandbox_policy":{"type":"danger-full-access"}
"permission_profile":{"type":"disabled"}
"originator":"Codex Desktop"
"source":"vscode"
"cli_version":"0.133.0"

Note: the rollout log contains source:"vscode", but I am not using VSCode. I am using the standalone Windows Codex App.

The standalone PowerShell CLI reports:

codex-cli 0.131.0

but the Windows Codex App session log reports:

cli_version: 0.133.0

So this may involve the embedded Windows Codex App runtime rather than only the standalone CLI installed on PATH.

Expected behavior:

When the effective runtime context is:

approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled

Codex should not ask for manual approval for normal shell commands or file edits.

Actual behavior:

The Windows Codex App still shows command approval prompts. For example, it asks whether to approve a command such as:

cargo test ...

The prompt offers buttons such as:

Approve
Approve for session
Decline

This is unexpected because the session metadata already says approval_policy=never and sandbox_policy=danger-full-access.

This does not appear to be a case where the session was downgraded to:

approval_policy=on-request
sandbox_policy=workspace-write

The log shows the opposite: the runtime context is already no-approval and full-access.

Therefore the issue appears to be one of these:

1. The Windows Codex App approval UI is ignoring the effective runtime permission context.
2. Tool execution still routes through an approval gate even when approval_policy=never.
3. There is a mismatch between rollout session metadata and the actual approval enforcement path.
4. The embedded Windows Codex App runtime differs from the standalone CLI on PATH.

Steps to reproduce:

1. Open the standalone Windows Codex App.
2. Start or continue a local repository session.
3. Grant Full Access.
4. Confirm that the local rollout JSONL contains:

approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled

1. Ask Codex to run a command or make file edits.
2. Observe that the Windows Codex App still asks for command approval.

Local rollout log path, redacted:

C:\Users\<redacted>\.codex\sessions\2026\05\28\rollout-2026-05-28T23-32-29-019e6f37-21d0-7630-af93-aba31d1b0dc9.jsonl

I can provide more redacted rollout JSONL excerpts if needed, but I will not attach full logs because they may contain local paths, prompts, commands, or repository-specific content.

What steps can reproduce the bug?

1. Open the standalone Windows Codex App.
2. Start or continue a local repository session.
3. Grant Full Access in the Codex App.
4. Confirm that the local rollout JSONL contains the following effective runtime context:

"approval_policy":"never"
"sandbox_policy":{"type":"danger-full-access"}
"permission_profile":{"type":"disabled"}

1. Ask Codex to run a normal command or make file edits.
2. Observe that the Windows Codex App still shows a command approval prompt, with options such as:

Approve
Approve for session
Decline

For example, the app still asks for approval before running commands such as cargo test ... or pnpm ....

This happens even though the session metadata already says approval_policy=never and sandbox_policy=danger-full-access.

What is the expected behavior?

When the effective runtime context is:

approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled

the Windows Codex App should not ask for manual approval for normal shell commands or file edits.

If Full Access is active, command execution should proceed without showing approval prompts.

If the app intentionally requires approval despite this metadata, the UI should clearly show the effective permission mode and explain why approval is still required.

Additional information

I am using the standalone Windows Codex App, not the VSCode extension.

Redacted rollout JSONL excerpts show:

"approval_policy":"never"
"sandbox_policy":{"type":"danger-full-access"}
"permission_profile":{"type":"disabled"}
"originator":"Codex Desktop"
"source":"vscode"
"cli_version":"0.133.0"

Note: the rollout log contains source:"vscode", but I am not using VSCode. I am using the standalone Windows Codex App.

The standalone PowerShell CLI reports:

codex-cli 0.131.0

but the Windows Codex App session log reports:

cli_version: 0.133.0

So the issue may involve the embedded Windows Codex App runtime rather than only the standalone CLI installed on PATH.

This does not appear to be a simple downgrade to:

approval_policy=on-request
sandbox_policy=workspace-write

The local session metadata shows the opposite: the session is already no-approval and full-access, but the approval UI is still triggered.

Local rollout log path, redacted:

C:\Users\<redacted>\.codex\sessions\2026\05\28\rollout-2026-05-28T23-32-29-019e6f37-21d0-7630-af93-aba31d1b0dc9.jsonl

I can provide more redacted rollout JSONL excerpts if needed, but I will not attach full logs because they may contain local paths, prompts, commands, or repository-specific content.