Definitive Guidelines for Blocking Sandboxing

[hybrid timber]

I have researched this and found pieces, but nothing definitive to block sandboxing. I'm hoping that someone who knows more about OC can help. My OC install is on a Ubuntu26 vm that I made specifically for it with the rights I wanted it to have. It was really great up until about a week ago after updating. Sandboxing shows up as default and now OC is acting like it got a lobotomy along with shackles.

I am using a native NPM install.

Yes, I've done this:
openclaw config set agents.defaults.sandbox.mode off (and validated this in openclaw.json)
openclaw gateway restart

I added this to my openclaw.json file as well:
"tools": {
"elevated": {
"enabled": true
},
"exec": {
"host": "gateway",
"ask": "off"
},

I've restarted the gateway, restarted the vm, and when OC starts I ask if it's in a container. It says "no, i'm on the host". I ask it to give me a listing of the project folder under workspace and it says it can't see a project folder because it's in a container. It then says that I should run the ls -la ~/.openclaw/workspace/project and tell it what files are there. I AM NOT MY AI'S ASSISTANT!

Any help or guidance would be appreciated.

[wet yacht]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[white arch]

First thing: please post openclaw --version, because this area changed recently and version mismatch matters.

There are two different “sandbox” layers that can look like the same problem:

1. OpenClaw’s own sandbox:
   agents.defaults.sandbox.mode: "off" is the right knob. To verify what the running gateway actually thinks, run:

openclaw sandbox explain --json
openclaw config get agents.defaults.sandbox
openclaw config get agents.list

Check for a per-agent override like agents.list[].sandbox.mode; that can override the default. Also, after sandbox config changes, docs say to recreate existing sandbox runtimes:

[white arch]

openclaw sandbox recreate --all --force
openclaw gateway restart

Only do that if you do not care about state inside old sandbox containers.

2. Codex/native harness sandboxing:
   If you are using the Codex app-server/runtime, agents.defaults.sandbox.mode=off only disables OpenClaw’s Docker-style sandbox. Codex can still run with its own permission/sandbox mode. The current normalized knob for the “trusted local operator / no approval” posture is:

openclaw config set tools.exec.mode full
openclaw gateway restart

Your tools.exec.ask: "off" helps with exec approvals, but for Codex harness sessions the docs specifically say tools.exec.mode: "auto" maps to Guardian/on-request/workspace-write, while tools.exec.mode: "full" is the intentional no-approval posture.

[white arch]

Docs:
https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated
https://docs.openclaw.ai/gateway/sandboxing
https://docs.openclaw.ai/plugins/codex-harness

If openclaw sandbox explain --json says sandboxed: false but the agent still refuses local files, paste that output plus openclaw --version. That points away from OC sandboxing and toward Codex/native tool policy or the session’s stale runtime state.

[hybrid timber]

@white arch I have done all of that. The input is as follows. As you can see, the openclaw config set tools.exec.mode full creates an error, and in my test it's still in a sandbox:

[white arch]

Thanks, that output is actually pretty decisive: OpenClaw sandboxing is off.

This line is the important one:

"sessionIsSandboxed": false

So don’t chase tools.elevated.allowFrom.webchat yet; elevated only matters when an OpenClaw sandbox is active.

Also: my earlier tools.exec.mode full advice was from newer docs/main. On 2026.5.27 (27ae826), that key does not exist yet, so the validation error is expected. For your version, the equivalent exec posture is:

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off

[white arch]

openclaw gateway restart

Now, the PID 1: catatonit / cgroup answer is almost certainly the Codex/native runtime inspecting its own execution environment, not OpenClaw’s sandbox. In 2026.5.27, Codex has its own app-server sandbox policy separate from agents.defaults.sandbox.mode.

If you are using the Codex harness, check:

openclaw config get plugins.entries.codex.config.appServer

For the “trusted local VM, no Codex sandbox” posture, try:

openclaw config set plugins.entries.codex.config.appServer.mode yolo

[white arch]

openclaw config set plugins.entries.codex.config.appServer.approvalPolicy never
openclaw config set plugins.entries.codex.config.appServer.sandbox danger-full-access
openclaw gateway restart

Then in the chat, test with something concrete rather than “are you in a container”, because that question can make Codex report its own native harness environment. Ask it to run:

Use the exec tool to run: pwd && ls -la ~/.openclaw/workspace/project

If that still refuses or still shows catatonit, run /codex status and paste the app-server policy section. That will tell us whether Codex is still being forced into guardian/workspace-write by its requirements.

Docs for this split:
https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated
https://docs.openclaw.ai/tools/exec

[white arch]

https://docs.openclaw.ai/plugins/codex-harness-reference