Codex Desktop: existing task repeatedly reverts to on-request approvals despite full-access/no-approval settings

Open 💬 2 comments Opened Jul 13, 2026 by Clouddylol

Summary

An existing Codex Desktop task repeatedly asks for file-edit approval even after the user chooses Allow always and even after global/per-task settings are changed to full-access/no-approval. The task rehydrates back to approval_mode = on-request whenever continued through background thread messaging.

Environment

  • OS: Windows
  • App: OpenAI Codex / ChatGPT Desktop
  • App package observed: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0
  • Affected task/thread: 019dfee1-c0dd-7323-966b-d9f63460807f
  • Task title: Microbot Recode
  • Project path: E:\Microbot-nightly
  • Old task source in local state: vscode
  • Old task CLI version in local state: 0.128.0-alpha.1
  • Current controller task CLI version observed separately: 0.144.0-alpha.4

Expected behavior

When permissions are set to full access / never ask, and the user chooses Allow always, Codex should not repeatedly prompt:

Allow ChatGPT to edit the following file?

Normal edits inside the trusted project should proceed without repeated modal approval prompts.

Actual behavior

The task repeatedly shows file-edit approval prompts for normal edits inside the trusted project, for example:

E:/Microbot-nightly/runelite-client/src/main/java/.../Rs2Dialogue.java

Clicking Allow always does not persist. The same approval prompt appears again shortly after on the next edit attempt.

Reproduction steps

  1. Open existing task 019dfee1-c0dd-7323-966b-d9f63460807f.
  2. Continue it from another Codex task using send_message_to_thread.
  3. Ask it to edit a file inside E:\Microbot-nightly.
  4. Observe a file-edit approval prompt.
  5. Click Allow always.
  6. Ask/allow another edit.
  7. Observe that the approval prompt returns.

Local state evidence

The task row in:

C:\Users\Clouddy\.codex\state_5.sqlite

repeatedly rewrites to:

  • approval_mode = on-request
  • sandbox_policy = managed/restricted

Even after manually setting:

  • approval_mode = never
  • sandbox_policy = {"type":"disabled"}

The JSON UI mirror at:

C:\Users\Clouddy\.codex\.codex-global-state.json

also gets rewritten from:

  • :danger-full-access
  • approvalPolicy: never

back to:

  • :workspace
  • approvalPolicy: on-request

when the old task is resumed.

Additional observed behavior

A canary edit attempt after permission repair still triggered approval immediately. The dev task reported:

Editing still triggered an approval/pending prompt, so I terminated it immediately. No new patch landed.

The old task is therefore unusable for unattended or delegated code edits even though the project is trusted and the intended global policy is no approvals.

Impact

This breaks long-running multi-task workflows where one task is the controller and another specific existing task is the required development task. It causes repeated blocking approval popups and makes Allow always unreliable.

Severity

High. It prevents unattended automation and invalidates the user's selected persistent permission mode.

Requested fix

Existing tasks should respect current global/project/task permission settings when resumed, or there should be a supported way to permanently migrate an old task from legacy on-request permissions to full-access/never.

Allow always must persist for the task/project and should not be overwritten by task rehydration.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗