Summary

When a Codex-backed agent is already running inside an OpenClaw-managed Docker sandbox, OpenClaw appears to force Codex app-server turns into Codex workspace-write mode. In some Docker sandbox environments this makes Codex try to start its own Linux/bwrap sandbox inside the outer sandbox, and shell/tool execution can fail before the command runs.

The desired behavior is a supported OpenClaw configuration option to use the OpenClaw sandbox as the single isolation boundary and run Codex inside that boundary without its inner bwrap sandbox.

Observed behavior

A minimal Docker-sandboxed Codex agent smoke reached the child session, but failed before running a basic shell command or reading a known workspace file.

Returned smoke result, sanitized:

SMOKE_STATUS: FAIL
TOOLS_USED: exec, exec_command
PWD: none
WORKSPACE_FILE_READ: FAIL
ERROR: bwrap loopback Failed RTM_NEWADDR Operation not permitted
NOTES: Shell execution was blocked before either check could run.

This issue is about Codex's inner bwrap sandbox failing inside an already sandboxed OpenClaw Docker runtime.

Environment shape

• OpenClaw version: 2026.5.12
• Runtime: Codex app-server / agentRuntime.id = "codex"
• OpenClaw sandbox: Docker, enabled for the agent
• Workspace access: read/write inside the OpenClaw-managed sandbox workspace
• Effective sandbox tool policy includes normal coding-agent fs/runtime tools

No host-specific paths are required to reproduce the issue.

Why this matters

For Docker-sandboxed agents, Docker/OpenClaw is already the trust boundary. Running Codex's own bwrap sandbox inside the container creates a nested sandbox/namespace failure mode and can prevent basic coding-agent shell execution.

Giving the Docker container broader privileges/capabilities to satisfy inner bwrap would weaken the outer sandbox. The cleaner design is to let OpenClaw own sandboxing and tool policy while Codex runs unsandboxed relative to the already-isolated container.

Requested behavior

Add a supported config option for Codex-backed agents such as:

• disable Codex inner sandbox when OpenClaw Docker sandboxing is active, or
• allow explicitly setting Codex sandbox mode to danger-full-access for Docker-sandboxed agents without OpenClaw narrowing it back to workspace-write.

Important constraint: this should not disable OpenClaw's outer sandbox or tool allow/deny policy. It should only avoid the nested Codex bwrap sandbox inside the already sandboxed execution environment.

Minimal repro shape

1. Configure a Codex-backed agent with OpenClaw Docker sandboxing enabled.
2. Give the agent normal fs/runtime tool exposure.
3. Spawn a tiny child task that runs pwd or reads a known workspace file.
4. Observe that shell execution may fail with:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Expected result

The child Codex agent should be able to run basic shell/file commands inside the OpenClaw Docker sandbox, while OpenClaw remains responsible for the sandbox boundary and tool policy.