Bug type
Regression / breaking change without migration path
Summary
After updating from a pre-sandbox version to 2026.4.1, a Docker sandbox container is automatically created and enabled for existing agents with no prior sandbox configuration. This silently breaks all exec tool calls — commands are blocked with "allowlist miss" and approval popups appear that cannot be dismissed or disabled.
The result is a complete loss of exec functionality for existing setups. There is no warning during startup, no migration guide, and no clear way to opt out. A working setup is broken with no path to recovery visible to the user.
Impact
- All cron-triggered exec commands fail silently
- Approval popups appear on every exec call and cannot be dismissed permanently
tools.exec.ask = "off" is ignored while sandbox is active
tools.exec.host = "gateway" is ignored while sandbox container exists
exec-approvals.json defaults (ask: "off", security: "none") are ignored
- Per-agent
tools.exec.ask = "off" is ignored
- The only fix is to manually destroy the Docker container (
docker rm -f openclaw-sbx-agent-main-*) — this is not documented anywhere
Time lost
Over 1 hour diagnosing this for a single-user local gateway setup that was fully functional before the update. None of the documented config options (ask, security, host) had any effect while the sandbox container existed.
Steps to reproduce
- Have a working single-user local gateway setup with agents using exec (Python scripts, cron jobs)
- Update to 2026.4.1 (pulls sandbox-related commits)
- Gateway starts normally — no warnings about sandbox activation
- Agent attempts any exec command
- Approval popup appears. Clicking "Always allow" has no persistent effect.
- Setting
tools.exec.ask = "off" globally and per-agent has no effect
- All cron exec jobs fail with "allowlist miss"
Fix required
- Sandbox must not be enabled by default for agents with no sandbox config
- OR: startup must warn clearly that a sandbox container was created and how to disable it
- OR:
tools.exec.host = "gateway" must bypass the sandbox container entirely
openclaw doctor --fix should detect and offer to remove orphaned sandbox containers
- Migration guide needed for users updating from pre-sandbox versions
Environment
- Version: 2026.4.1
- Platform: macOS, LaunchAgent gateway
- No Docker sandbox config in any agent before update
- Single-user operator setup
Bug type
Regression / breaking change without migration path
Summary
After updating from a pre-sandbox version to 2026.4.1, a Docker sandbox container is automatically created and enabled for existing agents with no prior sandbox configuration. This silently breaks all
exectool calls — commands are blocked with "allowlist miss" and approval popups appear that cannot be dismissed or disabled.The result is a complete loss of exec functionality for existing setups. There is no warning during startup, no migration guide, and no clear way to opt out. A working setup is broken with no path to recovery visible to the user.
Impact
tools.exec.ask = "off"is ignored while sandbox is activetools.exec.host = "gateway"is ignored while sandbox container existsexec-approvals.jsondefaults (ask: "off",security: "none") are ignoredtools.exec.ask = "off"is ignoreddocker rm -f openclaw-sbx-agent-main-*) — this is not documented anywhereTime lost
Over 1 hour diagnosing this for a single-user local gateway setup that was fully functional before the update. None of the documented config options (
ask,security,host) had any effect while the sandbox container existed.Steps to reproduce
tools.exec.ask = "off"globally and per-agent has no effectFix required
tools.exec.host = "gateway"must bypass the sandbox container entirelyopenclaw doctor --fixshould detect and offer to remove orphaned sandbox containersEnvironment