@@ -98,12 +98,13 @@ If you deploy the OpenClaw Gateway itself as a Docker container, it orchestrates
|
98 | 98 | |
99 | 99 | - **Config requires host paths**: The `openclaw.json` `workspace` configuration MUST contain the **Host's absolute path** (e.g. `/home/user/.openclaw/workspaces`), not the internal Gateway container path. When OpenClaw asks the Docker daemon to spawn a sandbox, the daemon evaluates paths relative to the Host OS namespace, not the Gateway namespace. |
100 | 100 | - **FS bridge parity (identical volume map)**: The OpenClaw Gateway native process also writes heartbeat and bridge files to the `workspace` directory. Because the Gateway evaluates the exact same string (the host path) from within its own containerized environment, the Gateway deployment MUST include an identical volume map linking the host namespace natively (`-v /home/user/.openclaw:/home/user/.openclaw`). |
101 | | -- **Codex code mode**: When an OpenClaw sandbox is active, OpenClaw constrains Codex app-server turns to Codex `workspace-write` sandboxing even if the Codex plugin default is `danger-full-access`. The Codex turn network flag follows the OpenClaw sandbox egress setting, so Docker `network: "none"` stays offline and `network: "bridge"` or a custom Docker network allows outbound access. Do not mount the host Docker socket into agent sandbox containers or custom Codex sandboxes. |
| 101 | +- **Codex code mode**: When an OpenClaw sandbox is active, OpenClaw disables Codex app-server native Code Mode, user MCP servers, and app-backed plugin execution for that turn because those native surfaces run from the Gateway-host app-server process instead of the OpenClaw sandbox backend. Shell access is exposed through OpenClaw sandbox-backed tools such as `sandbox_exec` and `sandbox_process` when the normal exec/process tools are available. Do not mount the host Docker socket into agent sandbox containers or custom Codex sandboxes. |
102 | 102 | |
103 | 103 | On Ubuntu/AppArmor hosts, Codex `workspace-write` can fail before shell startup |
104 | | -when the service user is not allowed to create unprivileged user namespaces. |
105 | | -When Docker sandbox egress is disabled (`network: "none"`, the default), |
106 | | -Codex also needs an unprivileged network namespace. Common symptoms are |
| 104 | +when you intentionally run native Codex `workspace-write` without active |
| 105 | +OpenClaw sandboxing and the service user is not allowed to create unprivileged |
| 106 | +user namespaces. When Docker sandbox egress is disabled (`network: "none"`, the |
| 107 | +default), Codex also needs an unprivileged network namespace. Common symptoms are |
107 | 108 | `bwrap: setting up uid map: Permission denied` and |
108 | 109 | `bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted`. Run |
109 | 110 | `openclaw doctor`; if it reports a Codex bwrap namespace probe failure, prefer |
|
