Codex Sandbox And Execution Policy

Last updated: 2026-05-03

This document records how Harness treats Codex sandbox and codex exec changes. For Codex 0.125.0 / 0.128.0 permission profiles, managed network hardening, codex exec --json telemetry, rollout tracing, codex update, and --full-auto deprecation policy, see docs/codex-permission-profiles-policy.md.

ひとことで

Harness は、remote environment ごとの sandbox 制約を requirements.toml の管理ポリシーとして案内します。 一方で、codex exec の shared flags 継承は Codex 本体の修正として受け取り、Harness wrapper では同じ flag を重ねません。

たとえると

requirements.toml は、建物ごとの入館ルールです。 本社では「閲覧だけ」、開発室では「作業机への書き込みも可」、一時的な検証室では「限定的に広い権限も可」のように分けます。

codex exec wrapper は、その建物に入る時の受付係です。 受付係が同じ許可証を二重に渡すと、どちらが正しいか分かりにくくなります。 そのため、Codex 本体が root-level shared flags を引き継げるところは本体に任せます。

Official References

• OpenAI Codex rust-v0.123.0 release: https://github.com/openai/codex/releases/tag/rust-v0.123.0
• Codex remote_sandbox_config PR: https://github.com/openai/codex/pull/18763
• Codex codex exec shared flags inheritance PR: https://github.com/openai/codex/pull/18630
• Codex config reference: https://developers.openai.com/codex/config-reference

Scope

This policy covers two Codex 0.123.0 items:

Upstream item	Harness surface	Harness decision
remote_sandbox_config in requirements	sandbox / admin execution policy	Document as a host-specific requirements.toml constraint. Do not put remote host policy into the shipped user config.toml.
codex exec inherits root-level shared flags	Codex wrapper scripts and setup docs	Treat as Codex automatic inheritance. Keep Harness wrapper defaults explicit only where they encode Harness intent.

remote_sandbox_config

remote_sandbox_config belongs to Codex requirements, not normal user setup defaults. Use it when an organization needs different allowed sandbox modes for different host classes.

Example:

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["devbox-*.corp.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

[[remote_sandbox_config]]
hostname_patterns = ["runner-*.ci.example.com"]
allowed_sandbox_modes = ["read-only", "danger-full-access"]

Comparison Table

Remote environment	Typical requirement	Example hostname_patterns	Allowed sandbox modes	Harness guidance
Managed developer laptop / local workstation	Prefer the global organization default	no remote override	["read-only"] or org default	Keep this in top-level allowed_sandbox_modes. Do not add a host override unless policy truly differs.
Remote devbox	Let agents edit the checked-out workspace, but avoid full host access	["devbox-*.corp.example.com"]	["read-only", "workspace-write"]	Use remote_sandbox_config so devboxes can work without weakening every host.
Ephemeral CI runner	Allow broader sandbox mode only for disposable automation hosts	["runner-*.ci.example.com"]	["read-only", "danger-full-access"]	Keep the pattern narrow and pair it with CI isolation. Do not use broad wildcards for persistent machines.
High-risk shared host	Force read-only even if users prefer a looser local config	["shared-*.corp.example.com"]	["read-only"]	Put the stricter host rule in requirements so local user config cannot weaken it.
Unknown host	Fall back to source precedence and top-level requirements	no match	top-level allowed_sandbox_modes	Treat hostname matching as best-effort classification, not device authentication.

Resolution Rules

• remote_sandbox_config is evaluated from the local hostname, preferring a fully qualified hostname when Codex can resolve one.
• Hostname matching is best-effort classification. It is useful policy routing, but it is not strong device identity.
• Each requirements source applies the first matching remote_sandbox_config entry before requirements are merged.
• Source precedence still matters. A lower-precedence matching host rule must not override a higher-precedence source that already constrained allowed_sandbox_modes.
• Harness should not copy these entries into codex/.codex/config.toml, because this is organization policy and belongs in requirements.

codex exec Shared Flags

Codex 0.123.0 fixed codex exec so root-level shared flags, such as sandbox and model options, are inherited by the exec subcommand.

Before this upstream fix, a command shaped like this could be misleading:

codex --sandbox read-only --model gpt-5.6-terra exec -

The root CLI parsed the shared options, but the exec command could still start with stale or default sandbox / model settings. Codex now merges the root selections into exec before dispatch.

Harness policy:

• Do not add duplicate --approval-policy / --sandbox pairs around codex exec.
• Prefer one source of truth per call: either root shared flags supplied by the caller, or an exec-local Harness default.
• Keep wrapper-provided sandbox flags only when they represent Harness workflow intent.
• Keep model selection out of wrappers unless a task explicitly needs a pinned model.

Wrapper Decision For 53.2.4

No runtime wrapper behavior changes in this task.

Wrapper	Current behavior	Decision
scripts/codex-companion.sh structured task mode	Converts Harness task --write into codex exec --sandbox workspace-write; defaults read-only when no write/sandbox intent is present; preserves explicit caller sandbox flags	Keep. This is not duplicate root shared flag forwarding. It is Harness semantic mapping for structured task execution.
scripts/codex/codex-exec-wrapper.sh	Runs codex exec - --full-auto after injecting hardening instructions	Legacy compatibility only. Do not copy this into new docs or new wrappers. Changing it would alter approval/sandbox behavior and needs a separate task with behavioral tests. It already avoids adding separate --approval-policy and --sandbox pairs.
scripts/codex-loop.sh local worker	Uses a full-access one-cycle background prompt for the loop runner	Keep outside this task. 53.2.4 is policy and wrapper duplication review, not a loop permission migration.

Verification Record

2026-04-23 checks added:

• tests/test-claude-upstream-integration.sh verifies this policy doc, the snapshot decision, Feature Table status, CHANGELOG mention, and wrapper comments.
• tests/test-codex-package.sh verifies the Codex README points users to this sandbox / exec policy.
• Existing validation keeps .claude-plugin/settings.json sandbox.failIfUnavailable and metadata endpoint denied domains intact.

Why This Way

Sandbox restrictions are security policy. If Harness silently rewrites them in a wrapper, users and administrators lose a clear place to reason about the effective boundary.

So Harness keeps the boundary simple:

• organization-wide and host-specific constraints live in Codex requirements;
• user/project runtime preferences live in Codex config or explicit CLI flags;
• Harness wrappers only add flags when they are expressing Harness workflow intent.

This lets Codex 0.123.0 improvements carry the shared flag inheritance, while Harness documents where each policy belongs.