OpenClaw merged PR #113892, tightening how Gateway exec commands behave when shell expansion prevents an enforceable execution plan.
The change is small, but the boundary matters. If approvals are disabled with ask=off and the configured askFallback is deny, an allowlisted exec command that includes shell-expanded arguments now fails immediately instead of waiting for an approval timeout.
What Changed
The PR targets a specific failure mode in Gateway-routed shell execution. Before this fix, a command could be allowlisted in principle, but shell expansion could keep the Gateway from producing the exact execution plan it needs to enforce the approval decision.
In that state, OpenClaw was still registering an approval request. With approvals disabled, the real exec caller saw an approval-pending result and then had to wait for the timeout.
After the merge, that same command is denied before the approval request is registered. The PR says prompt-enabled approval flows, executable allowlist plans, and node-host behavior are unchanged.
Why It Matters
Approval fallback settings are security policy, not UI preferences. When an operator says approvals are off and fallback should deny, the system should not create an ambiguous pending state.
The practical impact is clearer behavior for high-privilege automation:
- shell-expanded commands that cannot be safely planned fail closed
- operators get a clear denial instead of a delayed timeout
- approval queues avoid entries that can never be approved in the current mode
- existing prompt-enabled and enforceable allowlist paths keep their behavior
This is especially relevant for unattended or cron-driven agent work, where waiting for a timeout can make a failed command look like a stalled job rather than a deliberate security decision.
The Security Boundary
The important detail is not that shell expansion is forbidden everywhere. The fix is narrower: when shell expansion makes a Gateway execution plan unenforceable, and the current approval posture is deny-by-default with asking disabled, OpenClaw now honors that posture immediately.
That keeps the runtime aligned with the operator's configured intent. If a command cannot be reduced to a plan the Gateway can enforce, the fallback decision is applied at the decision point rather than deferred.
Validation
The PR includes a reproduction of the original behavior, where the Gateway registered an approval and the caller returned approval-pending. It then adds focused gateway and caller tests.
OpenClaw reports 117 focused tests passing, pnpm check:changed passing, and no accepted or actionable findings from autoreview.
For users, the visible change should be simple: affected commands fail quickly and explain that they were denied. For operators, the deeper win is policy consistency. A deny fallback now behaves like a deny fallback even when shell expansion complicates the exec plan.