PR #67468: fix(exec): do not resolve auto exec host to sandbox when mode is off (fixes #58885)

• Repository: openclaw/openclaw
• Author: armorbreak001
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67468

Description (problem / solution / changelog)

Background

After updating OpenClaw to a version with sandbox support (2026.4.1+), existing single-user setups without any prior sandbox configuration experienced completely broken exec functionality:

• All shell commands were silently routed through an auto-created Docker sandbox container
• Approval popups appeared on every exec call that could not be dismissed
• tools.exec.ask = "off" was ignored while sandbox was active
• Cron-triggered exec jobs failed with "allowlist miss"
• The only workaround was manually destroying Docker containers (undocumented)

Over 1 hour lost diagnosing per affected user. No migration warning was shown during update.

Root Cause

In src/agents/bash-tools.exec.ts, the resolveExecTarget() call computed sandboxAvailable as:

sandboxAvailable: Boolean(defaults?.sandbox)

This is truthy for ANY sandbox config object, including {mode: "off"} or even {}.

Since tools.exec.host defaults to "auto", and resolveExecTarget() resolves:

effectiveHost = resolvedTarget === "auto"
  ? (sandboxAvailable ? "sandbox" : "gateway")
  : resolvedTarget;

Any presence of agents.defaults.sandbox in config — even with mode: "off" — caused all exec calls to route through Docker sandbox.

Fix

1. src/agents/bash-tools.exec.ts (1 line changed)

- sandboxAvailable: Boolean(defaults?.sandbox),
+ sandboxAvailable: Boolean(
+   defaults?.sandbox?.mode && defaults.sandbox.mode !== "off",
+ ),

Now sandboxAvailable checks whether sandbox mode is actually enabled, not just whether the config object exists.

2. src/agents/bash-tools.exec-runtime.test.ts (regression test added)

Verifies that when sandbox = {mode: "off"}, auto resolves to "gateway" (not "sandbox").

Verification

Edge Cases

• Empty {}: mode is undefined → false → gateway (safe)
• Partial config without mode: same as above → gateway
• Explicit host: "sandbox": still works (separate code path that throws if sandbox runtime unavailable)
• Elevated mode (/elevated full): always uses gateway/node, unaffected

Fixes #58885

Changed files

• src/agents/bash-tools.exec-runtime.test.ts (modified, +37/-0)
• src/agents/bash-tools.exec.ts (modified, +2/-1)

PR #67501: fix(whatsapp): downgrade false-positive creds restore warning to debug

• Repository: openclaw/openclaw
• Author: armorbreak001
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67501

Description (problem / solution / changelog)

Summary

Fixes #60625

On every gateway startup and WhatsApp reconnect, the log emits a misleading [WARN] restored corrupted WhatsApp creds.json from backup message, even though creds.json and creds.json.bak are byte-identical with no actual corruption.

Root Cause

readCredsJsonRaw() returns null when creds.json is missing or empty (≤1 byte). During WhatsApp reconnect, the creds file is temporarily flushed, which triggers a backup restore. The restore path always logs at warn level regardless of whether the file was actually corrupt (real problem) or just temporarily unavailable (normal reconnect behavior).

Changes

extensions/whatsapp/src/auth-store.ts — maybeRestoreCredsFromBackup()

• Distinguishes between "file exists but contains invalid JSON" (corrupt → warn) vs "file missing/empty" (normal reconnect → debug)
• Restore from backup still happens in both cases (correct behavior preserved)
• Added credsCorrupt flag to track the reason for restoration

Before vs After

Verification

1. Normal reconnect (creds.json temporarily missing): warning disappears from user-visible logs
2. Actual corruption (invalid JSON): warning still fires at warn level
3. Valid creds.json: no log output (unchanged)

Changed files

• extensions/whatsapp/src/auth-store.ts (modified, +19/-4)
• src/agents/bash-tools.exec-runtime.test.ts (modified, +23/-0)
• src/agents/bash-tools.exec.ts (modified, +2/-1)