Support request: Codex desktop supplies 'on-request' approval policy despite project configuration saved as 'never'

Please investigate a recurring Codex Windows desktop permission-selection mismatch. It prevents our unattended workflow from passing preflight. The project requires approval_policy="never" within a restricted workspace-write profile; we are not requesting unrestricted execution or removal of the sandbox.

Environment: Windows build 26200; desktop package OpenAI.Codex 26.901.6511.0 (application metadata 26.901.51231, production flavor); native Codex 0.153.4. A local trusted saved project configures approval_policy="never", sandbox_mode="workspace-write", default_permissions="ite-digest", workspace networking and the elevated Windows sandbox backend.

The selected ite-digest profile is visible in runtime evidence, but fresh desktop tasks have repeatedly used on-request. Some previous tasks achieved never and progressed into the workflow. Switching desktop sign-in to API identity did not resolve the tested failure; the user confirmed the API identity in the app and has since returned to SSO. We have not established a subscription-plan restriction.

For failed task 01a0901c-e2d4-73e3-8385-a14d8a05bfcc on 11 September 2026:

• At 10:56:48.001 UTC, the desktop's “Reasoning summary turn-start config resolved” log, explicitly identifying this conversationId, records requestApprovalPolicy=on-request, resolvedApprovalPolicy=on-request, requestPermissionProfile=ite-digest and useAppServerPermissionDefault=false.
• At 10:56:49.403 UTC, the task transcript records effective approval_policy=on-request. The digest stopped before creating a run.
• At 11:01:47.908 UTC, a later resume log for the same task records no explicit permission request and responseApprovalPolicy=never. Its derivedApprovalPolicy=on-request describes the pre-response calculation; source review shows the response is subsequently mapped into currentPermissions.
  We are not presenting that derived field as proof of a second override.

Two read-only user-session log collections found the MSIX-redirected logs. The targeted follow-up completed without truncation or read errors. It confirmed four task-linked records and found ten nearby RPC method records without captured policy fields or task association. The missing startup inputs are therefore still unverified.

Separately, an isolated native app-server configuration test passed all 20 expected cases across five processes: configured defaults, named profile only and explicit never resolved correctly; explicit on-request controls also resolved correctly. That test required no model authentication and is not an end-to-end desktop comparison.

An offline reproduction using hash-pinned original desktop JavaScript identified a candidate mechanism. In the legacy task builder cno, Ig(auto, roots, config) derives the built-in on-request default, after which the named profile ID can be attached. The resulting fields contain on-request and ite-digest even when config specifies never. The explicit new-style named-profile path omits the approval override. All six original-function cases matched their assertions. Actual use of that legacy branch by the failed task remains unproven.

Please provide a supported diagnostic capture or confirm the relevant defect/fix for:

1. The actual config/read result and provenance used for this saved project.
2. The task builder's agentMode, profile ID, permissionSelection, override/default flags and applicable selection feature gate (4226282475 in this pinned build).
3. Correlated thread/start request/response permission fields and the inputs feeding the first turn/start policy. Selected outgoing turn fields are already evidenced above.
4. The supported way to retain project never plus the restricted named profile across fresh tasks, app restart and resumed tasks, while preserving explicit user approval choices.

Please scope any additional capture to configuration/permission metadata and task correlation. Do not request API keys, credentials, private project content or unfiltered conversation transcripts as part of this report. We have not patched the desktop app, changed the production plugin, relaxed its preflight requirement or uninstalled/reset the app.

Start with the legacy task builder path identified as cno and Ig(auto, roots, config), then compare it with the explicit named-profile path and the native app-server configuration test. Correlate the saved-project config, selection feature gate 4226282475, and thread/start permission fields; done means the policy provenance is established and the supported behavior or defect is confirmed.