OpenClaw’s 2026 Exec Routing and Approval Split

Between OpenClaw 2026.3.31 and 2026.4.2, shell execution stopped being one conceptual switch. It became a chain of distinct decisions: whether an agent had the exec tool, where a command should run, what the selected host would permit, and whether a person had to approve it.

The three stable releases arrived in roughly 46 hours, from 31 March to 2 April 2026. Their combined importance was not a single new sandbox feature or approval dialog. It was the separation of execution location from execution authorization—and the operational turbulence that exposed how easily those controls could be confused.

This is historical analysis, not a claim about every later OpenClaw version. We reviewed tagged releases, merged pull requests and the documentation shipped at the end of this sequence. We did not independently install or reproduce these old versions.

The historical change: one shell path, several gates

OpenClaw 2026.3.31 made node shell execution use exec host=node and removed the duplicate nodes.run shell wrapper from the CLI and agent tool. That consolidation mattered because command routing and approval could now meet on one execution path rather than being split across two public interfaces.

The same release established host=auto as routing logic: use a sandbox when a sandbox runtime is active for the session, otherwise use the gateway. Its tagged exec documentation was explicit that sandboxing remained off by default. An explicit host=sandbox, however, was supposed to fail closed when no sandbox existed rather than quietly running on the host.

That boundary came from PR #56800, merged on 29 March. The pull request says an implicit sandbox selection could fall through to direct host execution when no sandbox runtime was available. The patch made that case fail closed and added unit and seam tests. Upstream reported focused test reruns and a build, while noting it did not repeat a complete live Discord round trip on the combined branch.

This produced a useful distinction:

• auto was a routing strategy.
• sandbox was an isolation target that could fail to exist.
• gateway and node were real-host targets subject to host execution policy.
• tool allow/deny policy still decided whether exec was available at all.

A sandbox therefore did not replace approvals. Approvals governed an escape to a real host; sandbox configuration governed where isolated tool execution happened.

Why 2026.4.1 became the policy-repair release

OpenClaw 2026.4.1, published on 1 April, carried a cluster of exec-approval repairs rather than one headline feature.

It made exec-approvals.json defaults apply when inline or configured tool policy was unset. It changed “allow always” into durable trust instead of one-time permission, while preserving repeated prompts when policy explicitly said ask: "always". It also addressed isolated cron jobs that had no route for an approval prompt and added doctor warnings when tools.exec was broader than the host approvals file.

Those changes revealed the new operating model: requested policy in OpenClaw config was not the only authority. The execution host also kept local approval state. The effective result was the stricter combination.

The tagged 2026.4.2 documentation located that state at ~/.openclaw/exec-approvals.json and described three independent host-policy values:

1. security: deny, allowlist or full.
2. ask: off, on-miss or always.
3. askFallback: what happens when a prompt is required but no approval UI is reachable.

This explains why changing only tools.exec.ask could fail to produce the expected result. A stricter host file could still win, and a headless cron path could deny when no person was available.

2026.4.2 restored defaults but tightened the route

OpenClaw 2026.4.2, published on 2 April, made gateway and node host execution request security=full with ask=off by default. The release called this the no-prompt or “YOLO” default and aligned the host approval fallback and documentation with it. Operators wanting approvals had to tighten the policy explicitly.

At the same time, the release closed a different gap. PR #58897, merged shortly before the release, stopped treating configured host=auto as permission for a model-supplied host=gateway or host=node override. The pull request describes the old behavior as a sandbox-bypass regression: auto had acted like a wildcard for target authorization. Its focused runtime suite reported 12 passing tests; the PR’s recorded checks were predominantly successful, with one Windows test shard failing and several unrelated jobs skipped. We did not independently rerun that historical test matrix.

The release also shipped PR #59112. Invalid persisted values such as security: "none" had survived normalization and could produce inconsistent policy comparisons. The fix stripped malformed enum values so resolution fell back to documented defaults. Upstream reported the focused config test, build and check commands; we did not reproduce them.

The outcome was deliberately asymmetrical: default host execution could remain frictionless for a trusted operator, while a sandboxed session could not select a host escape merely by supplying a different target to the tool call.

Who this affected

The milestone mattered most to four operator groups:

• Node users had to replace the removed nodes.run shell path with exec host=node and understand that node pairing and node-local execution approval were separate concerns.
• Sandbox operators had to distinguish “sandbox enabled” from “host escape authorized.” Missing sandbox runtime and requested host overrides now had explicit failure behavior.
• Cron and headless operators had to account for askFallback; an approval workflow without a reachable approver is an availability failure, not a useful guardrail.
• Multi-agent operators had to verify per-agent tools.exec defaults. The 2026.3.31 release included a fix for those defaults being silently ignored when no session or inline override existed.

What operators had to learn then

The tagged 2026.4.2 model supported diagnosing command execution in this order:

1. Availability: is exec allowed by global and per-agent tool policy?
2. Location: does effective host resolve to sandbox, gateway or node?
3. Isolation: if sandbox is selected, does its runtime exist and what workspace/network does it expose?
4. Host policy: if gateway or node is selected, what do requested config and the host-local approvals file resolve to together?
5. Human path: if a prompt is required, can an authorized approval client receive it before timeout?

For that historical sequence, a more complete upgrade check than “can the agent run echo?” was to test one sandboxed command, one intentional host command, one denied command and one unattended job, then inspect the effective policy source for each. This is a reconstruction from the tagged behaviour, not a current runbook.

What the release sequence established

The March–April sequence separated sandboxing, tool availability and exec approvals because they answered different questions. In those releases, conflating route selection with permission could create both unsafe fallback and unexplained denial.

Its historical mental model was simple: routing chose the machine; policy chose whether the command could run; approval supplied an operator decision when policy asked for one. Later-version deployment guidance requires later-version sources.

Verification note: OpenClaw Academy checked the three official release records, merged status and timestamps for the cited pull requests, tagged 2026.4.2 documentation, and upstream test statements on 23 July 2026. Historical behavior and test results are attributed to upstream; we did not independently execute OpenClaw 2026.3.31, 2026.4.1 or 2026.4.2.