keep running into bwrap?

[lapis basalt]

Context:

Original issue was intermittent fallback on openai-api/gpt-5.5 with openai-responses:
rs_* not found / Items are not persisted when store=false, then misclassified as model_not_found.
Per Krill advice, I switched default to built-in openai/gpt-5.5.
To avoid Codex runtime behavior, I added:
"agents.defaults.models["openai/gpt-5.5"].agentRuntime.id": "pi"
Current default:
openai/gpt-5.5
Direct CLI test works:
openclaw agent --agent main --message "Reply with exactly: OPENAI_PI_ROUTE_OK"
returned OPENAI_PI_ROUTE_OK.

New symptoms:
Some topics/local tool operations are now failing before commands or edits run with sandbox-related errors.

Recent journal examples:

Subagent/shell sandbox:
All subagent spawn attempts are failing due to sandbox bwrap issues.

Earlier user-visible flavor:
local shell is failing before commands run: bwrap: setting up uid map: Permission denied

Edit-tool sandbox path issue:
[tools] edit failed: Could not edit file: /home/openclaw/.openclaw/workspace/projects/tpd/repo/app/prompts.py. Error: stat failed for /workspace/app/prompts.py: openclaw-sandbox-fs: 2: cd: can't cd to /workspace/app.

Local host checks:

kernel.unprivileged_userns_clone = 1
user.max_user_namespaces = 31611
bwrap is not installed:
bash: bwrap: command not found
unshare -Ur true as openclaw fails:
unshare: write failed /proc/self/uid_map: Operation not permitted
dpkg -l bubblewrap / command -v bwrap found nothing.

Question:
Is bubblewrap/uidmap now an expected runtime dependency for PI/local shell/subagent sandboxing in this setup, or is this only being exposed because of the recent model/runtime changes? Should I install bubblewrap uidmap and configure subuid/subgid for openclaw, or is there an OpenClaw-supported config path to avoid bwrap for this runtime?

Also, is the /workspace/app edit failure likely the same sandbox dependency issue, or a separate cwd/project-root mapping problem?

[marble tendon]

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

[worn heart]

Teduardo, short version: I would not treat bubblewrap as the main OpenClaw-supported sandbox dependency here.

I checked current docs/source. OpenClaw’s supported sandbox backends are docker, ssh, and openshell; sandboxing is optional and controlled by agents.defaults.sandbox. If sandboxing is enabled and no backend is set, OpenClaw defaults to Docker, not bwrap. Docs: https://docs.openclaw.ai/gateway/sandboxing and https://docs.openclaw.ai/tools/exec

What likely changed is routing/exposure, not that OpenClaw suddenly requires bwrap:

• agents.defaults.sandbox.mode="non-main" sandboxes non-main sessions. Discord/forum/thread sessions and subagents are usually non-main, so they can hit sandbox paths even when a direct CLI main-agent test works.
• tools.exec.host=auto resolves to sandbox when a sandbox runtime is active, otherwise gateway.
• If you want host shell execution even when sandboxing is configured, set tools.exec.host=gateway explicitly. If you want no OpenClaw sandboxing at all, set agents.defaults.sandbox.mode=off.

I would debug in this order:

openclaw --version
openclaw sandbox explain --agent main --json
openclaw config get agents.defaults.sandbox
openclaw config get tools.exec.host

[worn heart]

openclaw config get tools.exec.security
openclaw config get tools.exec.ask

For avoiding sandbox routing:

openclaw config set tools.exec.host gateway

For disabling OpenClaw sandboxing entirely:

openclaw config set agents.defaults.sandbox.mode off
openclaw sandbox recreate --all --force

[worn heart]

openclaw gateway restart

If you actually want sandboxing, use the documented backend path instead: Docker locally, or SSH/OpenShell remotely. Installing bubblewrap uidmap may help only if some nested PI/runtime sandbox path is being invoked, but your unshare -Ur true failure means the host/container is currently blocking unprivileged user namespaces despite the sysctl value, so packages alone may not fix it.

The /workspace/app edit failure looks more like a sandbox workspace mapping/cwd issue than the same bwrap dependency. In OpenClaw’s Docker sandbox, /workspace is the container workdir and the host mount source is only for the file-tool bridge. An error trying to cd /workspace/app while editing /home/openclaw/.openclaw/workspace/projects/tpd/repo/app/prompts.py suggests the tool/session thinks the cwd is /workspace/app, but the active sandbox workspace does not contain that path, or the project root was seeded/mounted differently. Check sandbox explain plus whether the sandbox was created before the workspace/project path changed; if yes, openclaw sandbox recreate --all --force is the right reset.

Also: please include openclaw --version with the next log snippet. Version skew matters a lot for this area.

[lapis basalt]

sandbox explain detail:

OpenClaw: 2026.5.19 (a185ca2)

Sandbox runtime:

openclaw-sbx-agent-main-f331f052

• Status: running
• Image: openclaw-sandbox-common:bookworm-slim
• Backend: docker
• Age: 1d 1h
• Idle: 12m
• Session: agent:main

Relevant config lines:

• agents.defaults.sandbox.mode = all
• workspaceAccess = rw
• agents.defaults.models.openai/gpt-5.5.agentRuntime = {"id":"pi"}
• browser.noSandbox = true

Recent precise error:
[tools] edit failed: Could not edit file: /home/openclaw/.openclaw/workspace/projects/tpd/repo/app/prompts.py. Error: stat failed for /workspace/app/prompts.py: openclaw-sandbox-fs: 2: cd: can't cd to /workspace/app.

Given the Docker sandbox is 1d old and predates several runtime/model/session changes, does this look like a good case for:

openclaw sandbox recreate --all --force

followed by gateway restart? Or should I inspect Docker mounts first?

[worn heart]

Yes, this is a good case for openclaw sandbox recreate --all --force.

Given:

• sandbox mode is all
• backend is Docker
• workspaceAccess=rw
• the runtime is already 1 day old
• it predates model/runtime/session config changes
• the failing path is a sandbox/container path mismatch: /workspace/app vs the real file under .../workspace/projects/tpd/repo/app/prompts.py

I’d do the low-cost inspection first only if you want to preserve evidence:

docker inspect openclaw-sbx-agent-main-f331f052 --format '{{json .Mounts}}'
docker exec openclaw-sbx-agent-main-f331f052 pwd
docker exec openclaw-sbx-agent-main-f331f052 ls -la /workspace

[worn heart]

docker exec openclaw-sbx-agent-main-f331f052 ls -la /workspace/app
docker exec openclaw-sbx-agent-main-f331f052 ls -la /workspace/projects/tpd/repo/app

If /workspace/projects/tpd/repo/app exists but /workspace/app does not, that confirms the edit tool/model is using a stale or wrong cwd/project-root assumption. Then recreate:

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

After restart, run the smallest repro from inside the same kind of session/topic, not only direct CLI main:

openclaw sandbox explain --agent main

[worn heart]

One caveat: browser.noSandbox=true is separate from agent/tool sandboxing. It affects browser launch behavior, not the Docker tool sandbox that is failing here.

If recreate fixes the path error but bwrap/uid_map errors remain, treat those as a separate nested runtime / host userns issue. This /workspace/app error reads like cwd/mount state first.