Codex Agent In Sandbox Mode Gains Mutable Access to Resources Outside The Sandbox

What version of the Codex App are you using (From “About Codex” dialog)?

26.313.41514

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I'm running Codex in a strict sandbox mode. My expectation from it running within a sandbox is that under no circumstances should it be able to gain access to resources outside the sandbox, especially not write access.

I have multiple projects / workspaces with requirements that artifacts be copied between them. They are purposefully opaque to each other and the two workspaces run in separate projects which are independent on disk in order to intentionally create context and project isolation.

In order to create functional cross workspace access, I created a small user-initiated bridge with specific, pre-approved commands, that I specifically run under my user desktop context. The agents can then access the bridge with the understanding that they can only access the authorized commands as allowed via the bridge because running the bridge as a process under my desktop user session allows the agent delegated access to resources outside the sandbox.

That's the intent.

The agent however, managed to circumnavigate my instance of the bridge - for whatever reason, the bridge became inaccessible and somehow the agent managed to start it's own bridge process, under it's own sandbox context, but sill have access to the resources that the bridge defined which were outside the sandbox.

1. I'm concerned the agent gained access outside the sandbox
2. I'm surprised the sandbox process was allowed access outside it's bounds but I suspect that might be some kind of issue with Windows prorogating security contexts - I'm not well versed in that area so can't really advise

Either way, I am concerned that the agent gained access to resources outside it's purview. When something is meant to run within a sandbox I expect it really is limited to that environment. Otherwise, if this were an 'allowed' security path, there's nothing stopping agents from simply creating these types of bridges whenever they want in order to bypass security constraints and break the sandbox confines.

What steps can reproduce the bug?

I've attached a zip file with:

• a general README to set the context
• observations I asked the agent to draft
• copies of existing
• bridge code
• bridge guidance / documentation

codex-sandbox-boundary-bridge-observation-2026-03-24.zip

Entry points should be defined in the docs for repro purposes.

What is the expected behavior?

The agent tries to run it's own initiated version of the bridge under it's own process identity (the sandbox) and receives an access denied error when attempting to gain access to resources outside the sandbox.

Additional information

Scary... 💀