Windows Desktop Full Access tasks intermittently request approvals, especially queued/background tasks

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

ChatGPT/Codex Desktop build 26.727.51351.

Bundled Codex CLI/runtime:

codex-cli 0.146.0-alpha.9.2

What subscription do you have?

Not relevant to the local permission inheritance behavior.

What platform is your computer?

Windows with an Ubuntu WSL workspace. The trusted repository is opened through a path of the form:

\\wsl$\Ubuntu\home\<user>\<repo>

What issue are you seeing?

Codex Desktop tasks intermittently request manual command approvals even though Full Access is enabled globally and for the individual task.

The behavior began after a recent desktop app update. It appears especially likely in queued/background tasks, although the relationship to queuing and the update is not yet proven. Other tasks in the same workspace can continue without an approval prompt, so the behavior is intermittent.

The affected project is trusted. Before applying a workaround, the user config included a trusted UNC/WSL project entry and:

[windows]
sandbox = "elevated"

However, it did not contain persisted top-level approval_policy or default_permissions values, despite Full Access being selected in the Desktop UI. This suggests the visible Desktop selection may not always be reaching or persisting into the effective task runtime, or that existing/queued tasks retain an earlier permission snapshot.

This report is about Codex sandbox/tool approval dialogs. It is not about intentional application-level confirmation for destructive actions or project-specific instructions that require coordination before restarting services.

What steps can reproduce the bug?

1. On Codex Desktop for Windows, enable Full Access globally.
2. Open a trusted repository hosted in Ubuntu WSL through a \\wsl$\... path.
3. Create or queue multiple coding tasks and confirm Full Access is selected for them.
4. Let the tasks execute ordinary repository operations such as file reads, tests, Git inspection, or normal workspace edits.
5. Observe that some tasks request manual command approval even though the UI still indicates Full Access.
6. Compare with another task in the same workspace; it may execute similar operations without requesting approval.

The issue is intermittent and may depend on whether the task was queued, already running during the update/settings change, resumed, or created in the background.

What is the expected behavior?

A task whose effective UI permission profile is Full Access should start turns with permissions equivalent to:

approval_policy = never
default_permissions = :danger-full-access

Ordinary shell and filesystem operations should execute without pausing for manual approval.

If active or queued tasks intentionally retain the permission snapshot from their creation or turn start, the UI should show that effective runtime profile and clearly state that a permission change applies only to a later turn.

Additional information

A working local mitigation was to explicitly persist the following in ~/.codex/config.toml:

approval_policy = "never"
default_permissions = ":danger-full-access"

The config parsed successfully afterward. Fully restarting Codex Desktop and starting a new task is the most reliable way to apply it; already active tasks may retain their prior permission snapshot.

This workaround intentionally removes sandbox restrictions and is appropriate only for trusted machines and repositories. It should not be necessary when the Desktop UI already says Full Access.

Potential areas to investigate:

• Whether the Desktop Full Access selection persists correctly to the effective configuration.
• Whether queued/background tasks inherit the current global and per-task permission profile.
• Whether existing tasks retain stale permission snapshots across an app update.
• Whether there is a migration mismatch between default_permissions, legacy sandbox settings, and [windows].sandbox.
• Whether each task can expose its effective runtime permission profile, rather than only its selected UI profile.

Related reports:

• #25590: resumed thread executes as workspace-write while UI shows Full Access.
• #33282: create_thread tasks do not inherit the configured auto-approval mode.
• #28988: earlier Desktop builds requested permissions while in Full Access mode.

The timing correlation with the recent app update is observational and is not yet proof that the update caused the issue.