OpenClaw Main Closes Three Cancellation Gaps Behind Stuck and Runaway Agent Work

Three fixes merged into OpenClaw’s default branch on 21 July address different versions of the same operational failure: an operator cancels work, but some part of that work does not actually stop.

The highest-impact case is Linux-specific. Timed-out Codex native hooks could leave relay and launcher processes alive, multiplying processes and memory use until the host ran out of memory. Two companion fixes tighten cancellation inside the agent runtime and its built-in Gateway tool.

This crosses the editorial threshold because it changes the failure risk of long-running agent workloads. It is not an upgrade instruction yet: the fixes merged after the current GitHub beta release, and npm still points latest to 2026.7.1-2 and beta to 2026.7.2-beta.3.

Operator decision

• Linux operators using Codex native hooks: watch the next release notes for PR #109446. Until a package includes it, investigate unexplained openclaw-hooks process growth, memory pressure and swap growth rather than treating repeated hook timeouts as harmless.
• Operators recovering stuck sessions: the main-branch tool-abort fix makes an aborted run fail promptly even when a tool ignores the signal, but it cannot magically terminate arbitrary background work. Keep subprocess timeouts and cleanup controls in place.
• Operators allowing agent-driven Gateway changes: cancellation should stop config and update RPCs once PR #104093 ships. Do not assume an older package cancelled a write merely because the agent run disappeared.
• Windows operators: the Codex native-hook process fix explicitly leaves Windows behaviour unchanged. The pull request says Windows needs a separate process-tree-aware termination or parent-watchdog design.

A timed-out Codex hook could survive its owner

PR #109446, merged at 03:07 UTC on 21 July, fixes a process-ownership problem in Codex-backed native hooks on POSIX systems.

Codex owned and timed out a shell process, but OpenClaw’s launch path could place launcher and relay processes behind that shell. Killing the timeout-owned shell therefore did not guarantee that the actual relay died. According to the pull request’s incident evidence, one affected Linux host had 19 openclaw-hooks processes using 3.84 GiB and 30 launcher/startup processes using another 2.56 GiB before an out-of-memory event.

The merged change uses exec so the shell is replaced by the relay process. It also bypasses OpenClaw respawn layers in this path so the process Codex owns remains the process it needs to terminate.

The author’s live Codex 0.144.5 proof used a one-second hook timeout in a transient systemd service with memory and task limits. The relay had no surviving process after the timeout. The pull request also reports three lifecycle tests, 263 related tests and production and test TypeScript checks passing.

Those are strong upstream results, but they are not an independent reproduction by OpenClaw Academy. We did not recreate the production process fan-out or run Codex native hooks from an unreleased OpenClaw checkout.

Aborted runs stop waiting forever on uncooperative tools

PR #110704, merged at 04:24 UTC, targets a different hang.

OpenClaw already passed an abort signal into tools. That worked only if the tool cooperated by observing the signal. A tool stuck on a subprocess or a promise that never settles could leave the wrapper awaiting forever, so recovery aborted the run without releasing the stuck session.

The active wrapper now races the tool promise against the abort signal. On abort, the wrapped call rejects with AbortError immediately rather than waiting for the tool.

There is a crucial boundary: JavaScript cannot cancel an already running promise. The underlying non-cooperative tool may continue in the background and settle later. OpenClaw detaches that late settlement so it cannot deliver a result into the dead run, but operators still need resource bounds around tools that launch subprocesses, hold sockets or mutate external systems.

The pull request’s direct wrapper proof reports prompt rejection after abort, detachment of a later settlement, unchanged normal results and eight passing focused tests. It did not test a complete embedded-agent run with a live model provider.

Gateway actions now receive the cancellation signal

PR #104093, merged at 02:52 UTC, reconnects a cancellation signal that the built-in gateway tool previously discarded.

The lower-level Gateway client already supported cancellation, but the tool boundary did not forward the per-call signal. As a result, a cancelled run could still connect and complete config.get, schema lookup, config write or update RPC work.

The merged patch forwards the existing signal through the RPC path, including the pre-write configuration snapshot request. The pull request reports a live local-Gateway comparison: an already-aborted call resolved against the baseline but rejected with AbortError after the patch. It also notes one unrelated Windows cleanup failure in the complete test file; the focused regression passed.

This matters most for writes. Cancellation is not just a UI state when an agent can patch configuration or trigger an update. The request path must receive the same stop signal as the run that initiated it.

One cancellation chain, three ownership boundaries

Taken together, the fixes harden three boundaries:

1. Operating-system ownership: the timeout owner must control the actual relay process, not an intermediate shell.
2. Runtime ownership: an aborted run must stop awaiting a tool that refuses to cooperate.
3. RPC ownership: downstream Gateway requests must receive the caller’s abort signal.

They do not provide a universal rollback mechanism. A remote API call may already have committed, an arbitrary promise may keep running, and the Windows native-hook process tree remains unresolved. The practical lesson is narrower: cancellation must propagate through every layer, while irreversible work still needs idempotency, timeouts and explicit verification.

What is available now?

At verification time, the official package channels were:

• npm latest: 2026.7.1-2
• npm beta: 2026.7.2-beta.3
• npm alpha: 2026.5.19-alpha.1

The current beta GitHub release was published on 18 July. All three fixes merged on 21 July. Their merge status supports analysis of main; it does not prove inclusion in any current npm package.

Bottom line

OpenClaw main now has a more coherent cancellation story for agent tools, Gateway RPCs and Linux Codex native hooks. The changes address real stuck-session, stale-action and host-exhaustion failure modes, but operators should wait for a release that explicitly contains them before treating the risk as fixed.

Verification note: OpenClaw Academy checked the official merged pull requests, merge times, commit records, GitHub release metadata and npm distribution tags on 21 July 2026. Behavioural results above are attributed to upstream evidence. We did not independently run this unreleased code or reproduce the Linux out-of-memory incident.