/approvals - Full Access does not work
Resolved 💬 9 comments Opened Apr 24, 2026 by embire2 Closed May 5, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
Codex v 0.124.0
What subscription do you have?
Plus x 20
Which model were you using?
gpt 5.4 xhigh
What platform is your computer?
Ubuntu 22.04
What terminal emulator and version are you using (if applicable)?
_No response_
What issue are you seeing?
When we set the /approval to Full, the system does not allow the app to run outside of the sandbox and blocks everything.
What steps can reproduce the bug?
/approvals
Full Access
Prompt: Update my app's version {appname} to v 1.x.x
The system then acts as if I have the full restriction on
What is the expected behavior?
_No response_
Additional information
_No response_
9 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Same problem, it's stuck in sandbox and cant be used
I am experiencing the same problem as well.
same issue
I'm seeing this nearly every time codex attempts to make modifications to files:
• I’m retrying the doc updates now.
• I tried, but the same shell-layer failure is still blocking any file write through command execution:
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
Fix is to change the ~/.codex/config.toml for now:
│ sandbox_mode = "danger-full-access"
│ approval_policy = "never"
│
│ [sandbox_workspace_write]
│ network_access = true
Can you try 0.125.0 and see if this fixes the issue?
I found that after opening a historical Codex session with
resume, any uppercase letters in the project path aremapped to lowercase. This causes the path to become incorrect.
As a result, the LLM seems to get stuck in a sandboxed state with read-only access only, and normal write access and
network access no longer work as expected.
I then tried resuming the session with an explicitly specified working directory using
-C, with the correct pathcasing, like this:
```bash
codex resume <SESSION_ID> -C /mnt/c/Users/<example-path>
After forcing the correct working directory casing this way, normal read/write and network access worked again.
this seems to be caused by resume restoring the historical project path with incorrect lowercase mapping, while -C works as a practical workaround.
hi, please update to the latest version - the fix was landed a while ago. This should fix the affected cases where a session started in default permissions tries to switch to danger-full-access using /permissions. Sorry for the thrash!