ExternalSandbox managed-network handling can weaken Require or downgrade to none

Resolved 💬 4 comments Opened Mar 26, 2026 by GraciousGazelles Closed Mar 26, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Observed while reviewing downstream carry of recent sandboxing changes.

Summary
The ExternalSandbox bypass path and managed-network / restrictive-policy handling need to stay fail-closed for Require semantics. If the bypass is applied too early or in the wrong shared decision point, the resulting sandbox choice can weaken Require behavior or downgrade to none.

Why this matters

ExternalSandbox should be a deliberate bypass only where policy allows it
Require semantics should not silently collapse to no sandbox
transform-path coverage matters, not only initial selection

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 5 months ago

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

#15524
#15309
#15305
#14367

Powered by Codex Action

etraut-openai contributor · 5 months ago

Can you say more about the problem? The description appears to be written by AI and is somewhat confusing. Can you provide repro steps for the bug?

GraciousGazelles · 5 months ago

Just to clear up the obvious weirdness here: the original version of this issue was raised by an AI agent I was using that took a bit too much initiative and auto-posted before I had properly reviewed and rewritten it myself. I’m fixing that on my side. Sorry about that.

The actual bug I was trying to report is narrower than that first post made it sound.

My concern is that ExternalSandbox can be treated too broadly as a bypass in shared sandbox-selection logic. In the path I was reviewing, that meant a request with restrictive semantics could end up resolving to SandboxType::None instead of staying fail-closed.

The two places I was worried about were:

initial sandbox selection
the later transform path before exec

A minimal code-level repro is:

Start with a request that has restrictive semantics, for example:

pref = Require
policy = SandboxPolicy::ExternalSandbox with restricted network access
a restrictive filesystem policy
network_policy = Restricted
managed-network enforcement enabled

In the buggy path, the shared selection logic can resolve that to SandboxType::None.

What I would expect instead is either:

choose a real platform sandbox, or
fail explicitly if that sandbox cannot be provided

It should not silently downgrade to no sandbox.

There is also a second part to the problem. Even if the initial selection is fixed, the transform path needs the same fail-closed behavior. Otherwise a restrictive request can still be turned into an unsandboxed exec request later in the pipeline.

So the narrower bug I meant to report is:

ExternalSandbox should only bypass the platform sandbox where policy explicitly allows that. It should not weaken Require semantics or let a restrictive managed-network request collapse into an unsandboxed path.

If it helps, I can also rewrite the issue body itself in this form.

etraut-openai contributor · 5 months ago

Thanks for the clarification. I'm going to close this issue. If you'd like to file a new one, please use the bug report template and provide the requested details.