›_ Codex Issues
Codex Issues / #36816

Full access mode doesn't work after the app restart

Open 💬 2 comments Opened Aug 4, 2026 by Pzixel
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.727.51351

What subscription do you have?

Pro x20

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

I keep asked for approvals despite using "Full access" mode

What steps can reproduce the bug?

Use "Full access" mode
Start a goal that requires some elevated privileges
Close the app
Start the app

The goal will continue automatically but then when some elevated action it will ask for permission, ignoring the "Full access" mode.

What is the expected behavior?

_No response_

Additional information

That is what codex has to say about this:

Why do I get those "approve" prompts despite "full access" mode active?

< Because this task’s permission profile changed mid-run. It started as unrestricted with approval policy never, but the latest environment context re-declared it as managed workspace-write with network access restricted. “Full access” still covers the repository filesystem, but production network calls are separately gated.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 24 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35860
  • #36530
  • #35638

Powered by Codex Action

YoYiL · 16 days ago

This is still reproducible on the current macOS desktop release:

  • ChatGPT Desktop: 26.803.61601 (build 6396)
  • Bundled Codex: codex-cli 0.147.0-alpha.6.5
  • macOS: 26.6.1 (Apple Silicon)

I can add a more specific trigger and state transition to this report:

  1. The composer and global setting continued to display Full Access.
  2. The affected task initially ran with approval_policy=never and

sandbox_policy=danger-full-access.

  1. After the task was resumed by a message sent from another Codex task (with no

permission-selector change), subsequent turn contexts switched to
approval_policy=on-request, sandbox_policy=workspace-write, and
active_permission_profile=:workspace, with network access disabled.

  1. The persisted per-task runtime state also recorded the restricted posture,

while the global composer setting remained full-access.

  1. The task then repeatedly waited for approvals and could no longer run

unattended. One of the prompts was for editing the workspace
.codex/config.toml, which is consistent with the effective workspace
profile rather than the Full Access profile shown in the UI.

The restricted state persisted across many later turns. Toggling/selecting Full
Access in the composer did not reliably repair the effective permissions of the
resumed task.

This looks like a current-version regression or an additional trigger for the
same UI/runtime permission desynchronization previously described in #24300:
the visible task setting says Full Access, but resumed/cross-task-delivered
turns execute and persist as workspace-write + on-request.

Expected behavior: resumed and cross-task-delivered turns should inherit the
task's current Full Access permission state. If the runtime intentionally
downgrades permissions, the UI should display the effective state before the
turn runs rather than silently waiting for approvals later.

I have omitted repository names, user paths, task/thread IDs, and raw logs, but
I can provide additional sanitized event excerpts if useful.