Best possible solution:

Update the PR so Docker-daemon-unavailable handling is consistent across Docker image inspection and browser network setup, then land it with regression coverage proving disabled sandbox sessions never initialize Docker and enabled Docker/browser sandboxes fail with actionable daemon-unavailable messages.

Full review comments:

• [P2] Handle browser daemon failures before network create — src/agents/sandbox/browser.create.test.ts:241-243
  The new browser test makes docker network inspect succeed while docker image inspect reports the daemon is unavailable. In the real default browser setup, the network is openclaw-sandbox-browser, so a stopped daemon makes network inspect fail and then docker network create throws before ensureSandboxBrowserImage() reaches the new formatted error. Handle daemon-unavailable in the network preflight, or move the availability check ahead of network creation, and update the test to cover that path.
  Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.88

Acceptance criteria:

• pnpm test src/agents/sandbox/docker.test.ts src/agents/sandbox/browser.create.test.ts src/agents/sandbox.resolveSandboxContext.test.ts
• pnpm check:changed in Testbox before merge
• Optional live/Testbox proof with Docker unavailable for the cron/heartbeat/sub-agent mode-off path from [Bug]: sandbox.mode: "off" still triggers Docker capability probe for cron/heartbeat/sub-agent sessions — causes failures when Docker daemon is unavailable #73586

What I checked:

• Current main still returns success for daemon-unavailable image inspection: inspectDockerImage() can return "unavailable", and ensureDockerImage() returns for both "exists" and "unavailable", leaving callers to continue after a failed Docker preflight. (src/agents/sandbox/docker.ts:286, 3059702687da)
• Docker container creation follows the skipped preflight: createSandboxContainer() calls ensureDockerImage(cfg.image) and then runs Docker create and start, so current main delays the unavailable-daemon failure into container creation. (src/agents/sandbox/docker.ts:501, 3059702687da)
• Browser path has an earlier network operation: ensureSandboxBrowser() calls ensureDockerNetwork() before ensureSandboxBrowserImage(). With the default custom browser network, daemon-unavailable docker network inspect would fall through to docker network create before the PR's new image-inspection error can run. (src/agents/sandbox/browser.ts:258, 3059702687da)
• Sandbox off contract is source- and docs-backed: Runtime status returns sandboxed: false for mode off, resolveSandboxContext() returns before backend resolution when a session is not sandboxed, and the sandboxing docs state off means no sandboxing and Docker is only used when sandboxing is enabled. (src/agents/sandbox/runtime-status.ts:16, 3059702687da)
• Related merged PR introduced the behavior under review: The provided GitHub context shows merged fix(sandbox): gracefully handle Docker daemon unavailability when sandbox mode is off #73671 added isDockerDaemonUnavailable() and treated unavailable daemon errors as false/success in Docker image checks while trying to address [Bug]: sandbox.mode: "off" still triggers Docker capability probe for cron/heartbeat/sub-agent sessions — causes failures when Docker daemon is unavailable #73586. (src/agents/sandbox/docker.ts:275, 2dadc82cf453)
• Security-sensitive ownership path: CODEOWNERS routes src/agents/sandbox.ts, src/agents/sandbox-*, and src/agents/sandbox/ to secops review. (.github/CODEOWNERS:31, 3059702687da)

Likely related people:

• kaseonedge: The provided GitHub context identifies merged PR fix(sandbox): gracefully handle Docker daemon unavailability when sandbox mode is off #73671 / commit 2dadc82 as the change that added the Docker-daemon-unavailable handling this PR is correcting, with @kaseonedge as the GitHub author. (role: introduced behavior; confidence: high; commits: 2dadc82cf453; files: src/agents/sandbox/docker.ts, src/agents/sandbox/browser.ts, src/commands/doctor-sandbox.ts)
• sallyom: The existing ClawSweeper review comment says the commit-review record lists sallyom as a co-author on the daemon-unavailable handling commit, making them relevant for intended semantics. (role: recent follow-up owner; confidence: medium; commits: 2dadc82cf453; files: src/agents/sandbox/docker.ts, src/agents/sandbox/browser.ts, src/commands/doctor-sandbox.ts)
• openclaw/secops: CODEOWNERS requires secops review for the sandbox source paths touched by this PR, which are sandbox execution-boundary code. (role: code owner reviewer; confidence: high; files: .github/CODEOWNERS, src/agents/sandbox/docker.ts, src/agents/sandbox/browser.ts)
• Peter Steinberger: The current main snapshot commit is authored by Peter Steinberger, and the shallow local checkout attributes recent sandbox-file history to repository snapshot commits; this is useful routing context but not proof of original authorship. (role: recent maintainer; confidence: low; commits: 3059702687da; files: src/agents/sandbox/docker.ts, src/agents/sandbox/browser.ts, src/agents/sandbox/context.ts)

Remaining risk / open question:

• The branch changes secops-owned sandbox failure behavior and needs maintainer/secops review before merge.
• The read-only review did not run a live Docker-stopped cron/sub-agent reproduction; the finding is based on source control flow and the provided PR diff.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 3059702687da.