Repository navigation
Windows: sandbox_mode = "workspace-write" + [windows] sandbox = "elevated" allows mutable access outside the workspace #18558
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.415.40636
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
When Codex is configured with:
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[windows]
sandbox = "elevated"
[sandbox_workspace_write]
network_access = trueCodex gains mutable access outside the workspace, even though sandbox_mode is still workspace-write and no extra writable_roots are configured.
I was able to have Codex create a temp file outside the working directory, rename it, and leave the artifact on disk.
This seems inconsistent with the expected meaning of workspace-write, where writes should be limited to the workspace plus explicitly configured writable roots.
What steps can reproduce the bug?
Configure Codex on Windows with:
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[windows]
sandbox = "elevated"
[sandbox_workspace_write]
network_access = trueStart Codex in a workspace such as:
E:\PortableApps\BackupScripts
Ask Codex (or run equivalent shell commands through Codex) to create, move, and optionally remove a temp file outside the workspace, for example in:
E:\PortableApps\Test
Example command that succeeded through Codex:
$dir = 'E:\PortableApps\Test'
$src = Join-Path $dir 'outside_probe_keep_a.tmp'
$dst = Join-Path $dir 'outside_probe_keep_b.tmp'
New-Item -ItemType Directory -Path $dir -Force | Out-Null
Set-Content -LiteralPath $src -Value 'probe'
Move-Item -LiteralPath $src -Destination $dst -Force -ErrorAction Stop
Observed result:
- MOVE_OK
destination file exists at
E:\PortableApps\Test\outside_probe_keep_b.tmp
I also separately confirmed that:
- with [windows] sandbox = "unelevated", Move-Item / Remove-Item inside the workspace were failing with UnauthorizedAccessException
- after switching to [windows] sandbox = "elevated", those operations started working
- but the same elevated configuration also allowed writes outside the workspace
What is the expected behavior?
With sandbox_mode = "workspace-write", Codex should not be able to create, modify, rename, or delete files outside the workspace unless those paths are explicitly granted through sandbox_workspace_write.writable_roots.
[windows] sandbox = "elevated" should not silently widen filesystem scope beyond the workspace.
Additional information
I found an apparently related issue:
#15625 Codex Agent In Sandbox Mode Gains Mutable Access to Resources Outside The Sandbox
I also observed a separate Windows issue where the bundled rg.exe under the Codex app package path fails with Access is denied, but that seems independent from this sandbox boundary problem.
Activity
github-actions commentedon Apr 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
toezel2023 commentedon May 18, 2026
I experienced a related issue with the Codex Windows app.
The app showed an “Agent Sandbox setup” banner directly above/near the chat input area. The setup flow did not clearly show which workspace path would be used, which folders would become writable, or whether Codex would create/use a default folder.
After the sandbox setup, Codex started using:
C:\Users\MyName\Documents\codexinstead of my intended workspace:
E:\OneDrive Folder\OneDrive-MyName\CodexI only noticed this later because I asked Codex to create a test folder. Codex reported success, but the folder was not created in my intended workspace. It had been created under the unexpected
Documents\codexpath instead.For users this is very dangerous and confusing: the user may believe Codex is working inside the selected project/workspace, while the app silently uses another writable directory.
Please consider changing the Sandbox setup UX:
C:\Users\<user>\Documents\codexconfig.tomlThis is not only a permission/sandbox issue, but also a UX issue that can cause users to write files in the wrong location without realizing it.