OpenClaw Code Mode Now Recovers From Failures Without Losing Its Restrictions

Three related fixes landed for OpenClaw’s Code Mode within roughly four hours of each other on August 22–23. Together they close a cluster of failure-path bugs where a crashed or rejected Code Mode run either wedged the agent’s tools or — in one case that deserves operator attention — could leave the toolset less restricted than policy intended after a Gateway restart.

The three failure paths

Preflight rejection stranded the bridge (PR #128054). When Code Mode’s startup preflight rejected a request, the bridge dispatch state was left inconsistent, so subsequent repair attempts were refused and the run stayed stuck with no clean way to retry. The fix introduces explicit per-run dispatch state — including a repairProvenance classification of clean, eligible, or invalid computed host-side — so the system knows which failures may be repaired automatically and preserves real network errors instead of masking them as generic failures.

Interrupted mutations got a read-only reconciliation turn (PR #128071). If a Code Mode mutation was interrupted mid-flight, retrying it blindly risked applying the same change twice; abandoning it left the agent and the workspace disagreeing about reality. The new reconciliation path is deliberately conservative: its injected prompt instructs the model not to repeat or finish any mutation, restricts the recovery turn to core read-only inspection tools (find, glob, grep, ls, read, search), requires a core-owned read entitlement, and preserves the original prompt’s read policy during recovery. The agent then reports what applied, what did not, and what remains unknown.

An unrelated failed wait could unlock Code Mode (PR #128098). After a Gateway restart, recovery logic that handles a failed wait did not bind itself to the specific tool call that failed — so a different, unrelated failed wait could flip Code Mode out of its restricted state even though nothing about the Code Mode session had legitimately changed. The fix ties failed-wait recovery to the exact tool call, and the PR description is blunt about the impact: users recovering after a restart could have Code Mode tools re-enabled without authorization. This one is effectively a small privilege-restore bug, and it is the reason this cluster warrants more than routine attention.

Why grouping them matters

Read separately, these look like minor plumbing fixes. Read together, they document a systemic issue: Code Mode’s state machine had multiple independent paths where failure handling mutated security-relevant tool restrictions or left runs unrecoverable. The maintainers’ sequence — repair provenance first, then read-only-only recovery, then binding state transitions to specific tool calls — shows a consistent hardening direction: recovery actions must be scoped to the exact failure, must not carry write authority, and must be classifiable as trusted before they run.

Operator guidance

• Update promptly if you use Code Mode, particularly with tools.exec approval policies or post-restart automation, since #128098 closes a restriction-bypass window that spans Gateway restarts.
• After upgrading, exercise one deliberate failure: interrupt a Code Mode mutation mid-run and confirm the next turn reports read-only reconciliation results rather than repeating writes.
• Do not treat reconciliation output as success. The design intent is honest uncertainty — “what applied, what did not, what remains unknown” — so downstream automations should require fresh confirmation before acting on recovered state.
• Review tool policy logs from August 22–23 if you run a gateway that restarted frequently in that window; unexpected Code Mode availability afterwards may indicate the unbound recovery path fired.

Interpretation note: the characterization of #128098 as a restriction-bypass fix follows the PR’s own problem statement; severity beyond that is our assessment. All three PRs are merged with test coverage added alongside the behavior changes.