OpenClaw merged an exec and sandbox reliability patch tonight in PR #165167, "fix(exec): stop stalled sandbox finalization and polling loops". The change addresses two related failures around quiet shell work and managed sandbox cleanup.
The PR is marked security-sensitive, but its immediate operator value is availability and diagnostics: OpenClaw should stop misclassifying valid long-running shell work as repeated blocked-tool stalls, and sandbox finalization should stop waiting indefinitely on container control commands.
What Went Wrong
Quiet shell commands can be legitimate. A build, test run, migration, or long-running process might produce little output while still owning a valid deadline. The bug was that OpenClaw could emit repeated blocked-tool warnings during that quiet period, even though the execution allowance was still valid.
At the same time, process polling included a changing idle-duration hint. That made otherwise unchanged polls look different enough to evade no-progress loop detection.
The second failure lived in managed sandbox workspace finalization. After a shell command exited, finalization could still wait indefinitely for container inspect, pause, or unpause commands. That is a bad place to lose control: the shell work is done, but workspace custody and cleanup are still unresolved.
What Changed
The patch uses existing owners instead of adding a new compatibility path. Container-control waits during managed-workspace finalization now use the existing 30-second lifecycle budget. If pause status is uncertain, OpenClaw retains receipts for recovery rather than pretending cleanup fully completed.
The polling fix removes elapsed time from the human input-wait hint while keeping structured timing fields. That restores stable outcome hashing, so unchanged polls can hit the existing terminal loop threshold.
In user terms, the behavior is simpler:
- Valid quiet work is reported as long-running, not repeatedly stalled
- Unchanged polls can terminate through the existing loop protection
- Sandbox finalization gets bounded container-control waits
- Recovery keeps authority when cleanup is uncertain
Why It Matters
OpenClaw's exec path sits between agents and real infrastructure. False stall warnings create noisy operator signals, while unbounded finalization creates harder operational risk: a run can appear finished while its sandbox lifecycle is still stuck.
This is exactly the kind of reliability fix that matters most under automation. Cron jobs, delegated work, and long-running build steps need quiet periods to be boring.
Verification
The PR reports 127 tests passing across 11 files on a Blacksmith Testbox with node scripts/run-vitest.mjs ... --maxWorkers=1. Seven new regression cases failed on the original production code for the intended reasons and passed after the change.
The production delta is small, but the outcome is meaningful: OpenClaw's shell and sandbox lifecycle now has clearer diagnostics and a firmer cleanup budget around managed workspaces.