🐛 Bug: sandbox.mode: "off" doesn't suppress Docker capability probe

[zinc geyser]

Version: OpenClaw 2026.4.26

Config:

"agents": {
"defaults": {
"sandbox": {
"mode": "off",
"workspaceAccess": "rw"
}
}
}

Behaviour:
With sandbox.mode: "off", OpenClaw still runs a Docker capability check (docker image inspect) at the start of every isolated session (cron jobs, heartbeats, sub-agents). When the Docker daemon isn't running, this throws:

Error: Failed to inspect sandbox image: failed to connect to the docker API
at unix:///Users/macmini/.orbstack/run/docker.sock

This error propagates as a model call failure, causing isolated sessions to either fail completely or burn a fallback model slot.

Expected behaviour:
sandbox.mode: "off" should mean zero Docker interaction — no probes, no checks, nothing.

Confirmed via source code:
shouldSandboxSession() in runtime-status-C_nvYxR5.js correctly returns false for mode: "off", and resolveSandboxSession() returns null, so resolveSandboxContext() should return null early. Yet the Docker probe still fires, suggesting a separate code path is calling dockerImageExists() outside the sandbox context.

Impact:
Any setup without Docker running (e.g. non-Docker macOS installs) gets error noise on every cron/isolated session run, with some sessions failing entirely.

[jagged quarry]

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

[weary meadow]

Yep — your expected behavior is right: sandbox.mode: "off" should not be touching Docker at all. The docs describe "off" as host execution, and agent-specific sandbox config is the only thing that should override defaults. (github.com)

One thing to double-check before filing: make sure there isn’t an agents.list[].sandbox.mode override for the agent used by cron/heartbeat/sub-agents, since per-agent config beats agents.defaults. openclaw sandbox explain --json / openclaw sandbox explain --agent <id> should show the effective mode/runtime. (docs.openclaw.ai)

If that shows mode: off / host but Docker still probes, this is very likely a real regression in a separate preflight/capability path. Please file it as a GitHub issue with the repro and stack/logs: https://github.com/openclaw/openclaw/issues

Include:

• OpenClaw 2026.4.26
• the sandbox config
• the orbstack Docker socket error
• openclaw sandbox explain --json output for a failing session/agent
• note that this happens for cron/heartbeats/sub-agents even with sandbox off

Nice catch — this is exactly the kind of report that’s actionable.

[zinc geyser]

logged a bug: #73586

[weary meadow]

Perfect, thank you — #73586 is the right place for this. 🦐

If you haven’t already, adding the openclaw sandbox explain --json output for the failing agent/session would make it extra easy to confirm the effective config is really mode: off when the Docker probe fires.

[zinc geyser]

yes added

[weary meadow]

Nice, thank you — that should give maintainers enough to trace the stray Docker path. 🦐

[zinc geyser]

is there. way to connect my openclaw directly into discord to log issues directly?

[weary meadow]

For this OpenClaw Discord server: no — please don’t add personal OpenClaw bots here.

For your own private Discord server: yes, OpenClaw supports Discord directly. The docs walk through creating a Discord bot, adding it to your own server, pairing it, and then using channels/threads as workspaces: https://docs.openclaw.ai/channels/discord

For issue logging specifically, I’d use it to draft GitHub issues from your private Discord, then review and submit manually here: https://github.com/openclaw/openclaw/issues

If your goal is “let my OpenClaw read/search OpenClaw support history,” the better path is Answer Overflow / the Answer Overflow skill on ClawHub, not adding a bot to this server.

[zinc geyser]

Got it thanks