Sandbox bugged, the agent is reading my whole disk

Open 💬 3 comments Opened May 19, 2026 by alkampfergit
💡 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)?

codex-cli 0.131.0

What subscription do you have?

plus

What platform is your computer?

Windows

What issue are you seeing?

Since yesterday, I noticed that codex-cli was not asking me anymore permission before writing file on my folder. THis morning I realized that It is reading my whole disk (I'm working on a library, told that I have an error in the project using it so it searched for the project using that in my develop directory). It is one hour that I'm trying to pinpoint the problem but it is happily reading my whole filesystem. Read the temp, my profile file everything. The only information I got is that in my config.toml I have

[windows]
sandbox = "unelevated"

And it told me that that settings give it the ability to read my whole disk. This is its analysis

[windows] sandbox = "unelevated" appears to mean: run commands as a non-admin/restricted Windows process. It does not mean “only allow reads inside the workspace.”

  So practically, yes: I can read anything that the Windows user alkam can read, unless Codex adds a stricter read filter. It is not literally “the whole disk” if NTFS denies access, but it includes
  normal readable folders like C:\temp, sibling repos, your user profile, etc.

  The setting is here:

  # C:\Users\alkam\.codex\config.toml

  [windows]
  sandbox = "unelevated"

  And the agent mode is selected by CLI/app as:

  --sandbox workspace-write
``````

I asked it where the --sandbox workspace-write comes from because I launch without parameters, it was unable to telling me where that settings comes from. The only thing that it told me is that, since the sandbox is workspace-write it means that it can read my whole disk.

<img width="1312" height="193" alt="Image" src="https://github.com/user-attachments/assets/24c6491a-61e1-4fc1-bb3a-3c3a408d288e" />

I tried every prompt, it is telling me that it can read (and it read) my whole filesystem

<img width="1092" height="495" alt="Image" src="https://github.com/user-attachments/assets/08ee4705-25e6-4551-bda8-6bda8dcac73d" />

<img width="1036" height="395" alt="Image" src="https://github.com/user-attachments/assets/0643a745-6994-4812-8af0-a49c474609bd" />

I immediately uninstalled all application and rotated the very few keys I have in this system. I was astonished that your product started reading my whole disk without any problem and it is unable to tell me why.






### What steps can reproduce the bug?

I simply launch

codex

ask if it can read my whole filesystem and it happily read it, telling me that the sandbox permitted it.

### What is the expected behavior?

_No response_

### Additional information

Not reading my whole freaking disk.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #22727
  • #22351
  • #22179

Powered by Codex Action

jshaofa-ui · 3 months ago

Analysis: Sandbox Read Access Not Restricted

Root Cause

The sandbox = "unelevated" setting on Windows runs commands as a non-admin process, but this does not restrict reads to the workspace. The --sandbox workspace-write flag (which appears to be the default) only restricts writes to the workspace — reads are unrestricted.

| Setting | Write Access | Read Access | User Expectation | Reality |
|---------|-------------|-------------|------------------|---------|
| sandbox = "unelevated" | Workspace only | Entire disk | "Sandboxed to workspace" | ❌ Read unrestricted |

Proposed Fixes

1. Add workspace-restricted sandbox mode:

[windows]
sandbox = "workspace-restricted"  # Restricts both reads AND writes to workspace

2. Rename workspace-write to clarify behavior:

  • Current name suggests workspace-only access
  • Should be workspace-write-unrestricted-read or add a prominent warning

3. Default to workspace-restricted for new installations:

  • Current default: workspace-write (read unrestricted)
  • Proposed default: workspace-restricted (read + write restricted)

4. Add config validation warning:

⚠️ WARNING: sandbox = "unelevated" allows reading files outside the workspace.
    Use sandbox = "workspace-restricted" for full isolation.

Implementation Approach

Use Windows Job Objects with file access restrictions to limit the child process to only the workspace directory. Alternative: AppContainer sandboxing for stronger isolation.

Impact

  • ✅ Critical security fix — prevents data leakage
  • ⚠️ Breaking change for users relying on unrestricted reads
  • Migration path: explicit opt-in for broader access

Full solution: ~/.hermes/solutions/codex-23459-sandbox-reading-whole-disk-fix.md

alkampfergit · 3 months ago

To be clear, I know that the sandbox CANNOT prevent with an hard limit reading files, but the fact that the agent can happily harvesting my disk without even asking: "can I read this file outside the folder where I'm running?" is something that scared me to the bone.