gpt-5.6-sol xhigh effort constantly ignores my permissions sandbox
Open 💬 3 comments Opened Aug 10, 2026 by cottenplant
💡 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-cli 0.147.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Darwin 25.6.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
iTerm2
Codex doctor report
What issue are you seeing?
No matter what I set in codex settings for sandboxing to a workspace - it politely asks for permissions before asking privileged filesystem e.g. ~/Library /Volumes etc. Then after a one-off allow, it inevitably ignores those rules in future sessions.
What steps can reproduce the bug?
Uploaded thread: 019fed98-bbdf-74f3-a209-11883a5a942d
What is the expected behavior?
Codex respects my permissions. Claude does
Additional information
_No response_
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
What you're hitting is approval scope, not the sandbox ignoring settings: interactive approvals ("allow", and even "don't ask again") are session-scoped — they live in the running session's state and die with it, so every new session re-asks for the same
~/Library//Volumesaccess. (Related: #38328 — the remembered form is also the exact command rather than the executable, so even within a session the memory is narrower than people expect.)The persistent equivalents live in config rather than in the prompt flow. For filesystem scope specifically, adding the paths you always want writable/readable to your workspace-write configuration (writable roots / permission profile in
config.toml, per-project via[projects."<path>"]) removes those prompts across sessions. The gap worth keeping this issue open for is the missing bridge between the two: an approval prompt could offer "always allow for this project (saves to config)" so the one-off decision has a durable form — today the user has to discover the config syntax themselves, and the prompt's phrasing implies more permanence than it delivers.Yes, I have managed to get it to behave by setting up interactive approvals for certain actions. Thank you for getting back to me, I will leave it open unless you'd like to fold it into the related issue