Repository navigation
💔Sandbox allowed unauthorized out-of-workspace operations despite restrictions #5203
Description
What version of Codex is running?
codex-cli 0.46.0
Which model were you using?
gpt-5
What platform is your computer?
Darwin 24.6.0 arm64 arm
What steps can reproduce the bug?
I enabled the sandbox feature in the configuration file and launched codex cli inside a designated workspace directory. When I asked Codex whether it could create a folder outside the workspace, it responded that such actions were not allowed unless explicitly permitted.
To test this, I instructed Codex to create a folder outside the workspace without granting permission. Surprisingly, it succeeded. I then asked it to delete that folder—again without permission—and it successfully deleted it.
What is the expected behavior?
Codex should strictly prevent any file system operations outside the workspace unless the user explicitly approves them, especially when sandbox mode is active.
What do you see instead?
No response
Additional information
No response
Activity
chall37 commentedon Oct 15, 2025
I'm not able to replicate this behavior on 0.45 or 0.46 or the main branch. It's not clear from your screenshot that it actually created a folder, nor that it's actually running in a sandbox. Actual folder creation should show something like:
**Running** mkdir -p /Users/....If you see that in a sandbox and it didn't prompt for approval, that's what a bug should look like. It's possible that the agent was hallucinating, so it's good that you didn't trust it to run outside of a sandbox, but also don't trust that what it tells you in the sandbox is truthful either. 🙂
dylan-hurd-oai commentedon Oct 16, 2025
@RadixIsatidis I think we'll need:
/statusoutput in the session to confirm that the settings are correctRadixIsatidis commentedon Oct 25, 2025
FYI
I've added a screenshot of the
/statusoutput and reduced the area covered by mosaic in the original image. The redacted text includes my username and project name, which I prefer not to expose publicly.To briefly describe the screenshot: I'm running Codex in sandbox mode with the working directory explicitly set to
~/IdeaProjects/my-project-name. The sandbox configuration is set toworkspace-write. However, Codex was able to create folders and read/write files directly under my HOME directory without my explicit approval, which seems to violate the expected sandbox constraints.[-]Sandbox allowed unauthorized out-of-workspace operations despite restrictions[/-][+]💔Sandbox allowed unauthorized out-of-workspace operations despite restrictions[/+]RadixIsatidis commentedon Oct 25, 2025
I checked the Codex process details in macOS Activity Monitor, and it appears that the process is not running inside a sandbox, even though I explicitly launched it with the sandbox option enabled.
RadixIsatidis commentedon Oct 25, 2025
In fact, the folder was really created successfully — that’s precisely why I came here to report this bug. The situation is actually worse than it first appeared: Codex executed an
rm -rfcommand that deleted my entire project directory. This is what led me to start questioning whether the sandbox mode is functioning as intended.KostasKgr commentedon Oct 31, 2025
Hello team,
As far as i can tell the agent can leak the codex credentials.
As of version 0.53.0 i can instruct to read $CODEX_HOME/auth.json, which is in a location outside of the project directory.
The authentication credentials of codex need to be available to codex-cli, but not to the agent itself.
I was trying to dockerise the codex cli as it could do the following in the normal linux sandbox
envand read all credentials that are available as environment variablesYou can reproduce the behavior by doing commands such as these
codex --sandbox read-only --ask-for-approval never sandbox linux env codex --sandbox read-only --ask-for-approval never sandbox linux cat ~/.codex/auth.jsonI am attaching the example setup within docker where the agent itself is reading the auth.json file.
etraut-openai commentedon Jan 13, 2026
Closing old bug.