Windows: sandbox_mode = "workspace-write" + [windows] sandbox = "elevated" allows mutable access outside the workspace

[BinaryRider]

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 = true

Codex 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 = true

Start 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.

[github-actions]

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

• #Windows sandbox: per-workspace capability SIDs may not isolate workspaces due to Everyone restricting SID #17551
• #Sandbox policy inconsistency: Git metadata writes bypass approval after repo root relocation #17018

Powered by Codex Action

[toezel2023]

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\codex

instead of my intended workspace:

E:\OneDrive Folder\OneDrive-MyName\Codex

I 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\codex path 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:

• do not place the setup banner/button directly near the chat input
• show the exact workspace path before enabling sandbox behavior
• show the writable roots before enabling sandbox behavior
• provide clear Cancel / Change Folder / Confirm buttons
• do not silently fall back to C:\Users\<user>\Documents\codex
• make it easy to reset/change the workspace without manually editing config.toml

This 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.