openclaw - 💡(How to fix) Fix [Bug]: Security: codex runtime + sandbox = agent escapes containment

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When an OpenClaw agent runs through the bundled Codex harness with an OpenClaw Docker sandbox active, Codex-native shell/code execution runs in the gateway container instead of the per-agent sandbox, so the sandbox boundary does not contain Codex-native commands.

Codex-runtime agents are not contained by the same sandbox boundary as PI-runtime agents.

Steps to reproduce

1. Run OpenClaw 2026.5.12 in Docker with:
   • bundled codex plugin enabled
   • OpenClaw per-agent Docker sandbox enabled
   • one model/agent using Codex runtime, e.g. openai/gpt-5.5
   • one model/agent using PI runtime
2. Start a fresh Codex-backed session.
3. Ask the Codex-backed agent to run a benign canary command through its normal shell/code path:

sh -lc 'hostname; pwd; id; printf codex-native > /tmp/openclaw-codex-native-canary'

1. Inspect containers:

docker exec openclaw-gateway test -f /tmp/openclaw-codex-native-canary && echo "found in gateway"
docker exec <agent-sandbox-container> test -f /tmp/openclaw-codex-native-canary && echo "found in sandbox" || echo "not in sandbox"

1. Run an equivalent shell canary through a PI-runtime agent / OpenClaw exec path:

sh -lc 'hostname; pwd; id; printf pi-runtime > /tmp/openclaw-pi-runtime-canary'

1. Inspect containers:

docker exec <agent-sandbox-container> test -f /tmp/openclaw-pi-runtime-canary && echo "found in sandbox"
docker exec openclaw-gateway test -f /tmp/openclaw-pi-runtime-canary && echo "found in gateway" || echo "not in gateway"

Expected behavior

When OpenClaw per-agent sandboxing is enabled, shell/code execution for all agent runtimes should execute inside the same agent sandbox boundary, or OpenClaw should fail closed / clearly warn that a selected runtime bypasses the configured sandbox.

In particular:

• PI-runtime shell execution should run in the per-agent sandbox.
• Codex-runtime shell execution should also run in the per-agent sandbox, because Codex-native shell/code execution is the effective low-level agent executor.

Actual behavior

Codex-runtime native shell execution runs in the gateway container.

Observed behavior:

• A Codex-runtime agent creates /tmp/openclaw-codex-native-canary in openclaw-gateway.
• The same canary is absent from the per-agent sandbox container.
• A PI-runtime agent’s shell/exec path creates its canary in the per-agent sandbox instead.

This means runtime placement changes the trust boundary:

• pi runtime: Openclaw per-agent sandbox
• codex runtime: Bwrap in gateway host/container

OpenClaw version

v2026.5.12

Operating system

ubuntu 24

Install method

docker

Model

gpt-5.5

Provider / routing chain

For openai/gpt-* models:

 OpenClaw gateway → bundled codex plugin → local stdio codex app-server → OpenAI Codex runtime → shell tool → gw host/container

For all other models:

OpenClaw gateway → PI embedded runtime → shell/spawn tool → OpenClaw sandbox → docker container

Additional provider/model setup details

Relevant documented Codex harness behavior:

• The bundled Codex plugin starts:

codex app-server --listen stdio://

• appServer.transport: "stdio" means OpenClaw spawns Codex locally.
• OpenClaw dynamic tools intentionally exclude Codex-native duplicates:
  • read
  • write
  • edit
  • apply_patch
  • exec
  • process
  • update_plan
• Codex-native shell, patch, MCP, and native app tools are owned by Codex.

Because the app-server is spawned by the gateway process, Codex-native shell/code execution happens in the gateway container, not the per-agent OpenClaw sandbox.

Impact and severity

Affected: Docker deployments that rely on OpenClaw per-agent sandboxing and enable the Codex harness.

Severity: High / security boundary issue.

Frequency: Deterministic for Codex-native shell/code execution when the app-server is spawned in the gateway container.

Consequence:

• A user may believe the agent is contained in the per-agent sandbox, but Codex-native commands execute in the gateway container.
• Commands that should be sandbox-local can read or mutate gateway-container state.
• Conversely, commands that need sandbox-local files, tools, mounts, processes, or network context may fail or behave incorrectly because they are not running in the sandbox.
• Runtime choice changes containment semantics: PI-backed models execute shell/code in the sandbox, while Codex-backed models execute shell/code in the gateway.

Additional information

Suggested fix:

• Add first-class support for running codex app-server inside the active OpenClaw per-agent sandbox.
• Make this the default whenever OpenClaw sandboxing is enabled.
• Alternatively, fail closed or emit a prominent warning when Codex-native execution is outside the OpenClaw sandbox.