Support per-command sandbox exclusion rule without bypass permission or review

Open 💬 3 comments Opened May 3, 2026 by skyfackr

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI

What feature would you like to see?

I would like Codex to support a per-command sandbox exclusion mechanism, similar to Claude Code's sandbox.exclude configuration field.

The desired behavior is that when the original command requested by the agent matches a configured pattern, Codex automatically runs that command outside the sandbox, even if the agent requested a normal sandboxed execution.

This is not the same as the existing exec policy allow decision. An exclusion rule should only decide sandbox placement. It must not grant permission, bypass review, or override any existing approval, deny, or prompt policy. If a matching command would otherwise require approval, it should still require approval. If another rule forbids it, it should still be forbidden.

In other words, this feature should separate "where the command runs" from "whether the command is allowed to run."

For example:

sandbox_exclude = [
  ["gh"],
  ["xcodebuild"],
]

Or as part of the existing rule system:

prefix_rule(
    pattern = ["gh"],
    decision = "prompt",
    sandbox = "outside",
)

Use case: tools such as gh need access to normal user auth state, for example ~/.config/gh/hosts.yml, which may intentionally not be exposed inside the sandbox. I want gh to run outside the sandbox so it can access its normal credentials, but I do not want to allow gh automatically or remove the approval prompt. This is specifically about forcing the matching command out of the sandbox while preserving the existing permission and review model.

Additional information

_No response_

View original on GitHub ↗

3 Comments

etraut-openai contributor · 3 months ago

Codex already supports this feature! See this documentation details.

skyfackr · 3 months ago

@etraut-openai Thanks for the quick response.

I am already aware of the existing rules feature. As I understand it, rules control whether a tool call should be allowed, prompted/reviewed, or rejected. My request is about a separate dimension: where the command runs.

I also re-checked this behavior with Codex. A command matched by a prompt rule does not automatically run outside the sandbox after the auto review approves it. This is different from commands matched by allow, which can bypass the prompt and also behave as escalated/unsandboxed. So the current behavior does not provide a way to say: “run this command outside the sandbox, but still preserve the prompt/review policy.”

The distinction I want is:

Command A should always run outside the sandbox, regardless of whether the agent explicitly requested escalation, but each invocation should still follow the existing prompt/review policy.
Command B should be allowed without prompting, but only when it runs inside the sandbox.

With the current behavior, these two controls appear to be coupled. I can effectively “allow both” or “deny both”, but I cannot independently control sandbox placement and permission/review behavior.

This is also why I mentioned Claude Code’s sandbox exclusion setting in the issue body. In Claude Code, the sandbox exclusion mechanism is a sandbox setting, separate from the permission rules. That is the model I think Codex should learn from: sandbox policy decides where a command runs, and permission policy decides whether it may run without review, must be reviewed, or should be rejected.

Concretely, I am requesting a separate sandbox-placement rule, for example:

sandbox_exclude = [
  ["gh"],
  ["xcodebuild"],
]

or something integrated into the existing rule system:

prefix_rule(
    pattern = ["gh"],
    decision = "prompt",
    sandbox = "outside",
)

The important part is that sandbox = "outside" should not imply allow, and allow should not imply sandbox = "outside".

I would also suggest changing the semantics of allow so that it only means “bypass the prompt/review,” while still keeping the command inside the sandbox unless the agent explicitly requests escalation or the user has configured a separate sandbox exclusion rule. If a user wants both behaviors — no prompt and always outside the sandbox — they should configure both allow and a sandbox exclusion rule.

Given this distinction, could you please reopen this issue? I do not think it is a duplicate of the existing rules feature. The existing rules feature controls permission/review decisions; this request is about independently controlling sandbox placement.

axelcursive · 3 months ago

I’m running into this too, and having this separation would be very useful.

In my case, there are commands that do not work correctly inside the sandbox because they need access to normal host state, sockets, credentials, or daemon-managed resources. I still want Codex to ask me before running them, but once approved I want them to run outside the sandbox automatically.

Right now I can add a prompt rule, but that only controls approval; it doesn’t seem to control where the command runs. And using allow is not what I want, because I don’t want to skip the approval step.

So the distinction proposed here feels exactly right to me: one policy dimension for whether a command is allowed/prompted/forbidden, and another for whether it should run inside or outside the sandbox.