write only sandbox doesn't work inside a container
What version of Codex CLI is running?
codex-cli 0.131.0
What subscription do you have?
pro
Which model were you using?
gpt-5.5
What platform is your computer?
Fedora Linux 43
What terminal emulator and version are you using (if applicable)?
bash
Codex doctor report
What issue are you seeing?
I'm running codex to try and avoid annoying approvals for writes in the workspace:
codex --sandbox workspace-write --ask-for-approval untrusted
If I ask it to write a TEST file I see:
Would you like to make the following edits? Reason: command failed; retry without sandbox?
And if I do yes, codex often writes python scripts that just write to files. This is completely insane and is wasting a ton of tokens.
I'm running codex inside of a podman container, so I suspect the nested bwrap is conflicting. I do NOT want to run privileged because I don't want to give codex more perms. I do want it to write normally as if I had disabled the inner sandbox. I don't want to disable the sandbox for anything other than file writes.
What steps can reproduce the bug?
Open codex cli inside a podman container by running: codex --sandbox workspace-write --ask-for-approval untrusted. Ask it to write a TEST file.
What is the expected behavior?
It should just work without a sandbox error. It should ask me for permission though if I've set to untrusted.
Additional information
NOTE: This used to work just fine, but broke in some recent update within the last 2 months or less I believe.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Related but not a dupe if you look at the specifics I mention in terms of what the user should expect to see happen.
Codex security and design really is... something. I'm running the entirely of codex inside my own bwrap container because I don't trust it. But as mentioned in this issue, when codex tries to spawn a child bwrap to accomplish a task, this fails! I'm not going to give the root-like privs to allow nested bwrap, that would defeat the point.
But if you disable needing bwrap with
codex --sandbox danger-full-accessthis also disables the yes/no "do I want to accept this edit" prompts, which I do want so I can easily say no and guide codex back on track!So what did I do today? I asked codex to create a shim bwrap which just passes things through... It was able to do this without needing any special perms. It added to
~/.npm-global/bin/bwrapthe below script.It didn't need any special perms to do so. And now I run
codex --sandbox read-only --ask-for-approval on-requestand things work as expected.Should be a good example of why codex security is fake nonsense AFAICT.
HTH
PS: As a side note, I've noticed pretty serious degradation in ability within the last two weeks... Something weird is going on and my personal research seems to indicate that openai (maybe at the request of the U.S. government) have deliberately "nerfed" the model. GPT5.5 pro.
XXX: codex built this to deal with the nested bwrap buggy garbage