OpenClaw Main Stops Rate-Limit Retry Storms as Doctor Previews Which Automations Will Lose Access or Pause
No new release landed this weekend, but OpenClaw's main branch now backs off from provider rate limits instead of retrying in lock-step or rerunning stalled turns, and Doctor previews which scheduled automations will lose access or pause. Plus: owners can ask an agent to maintain its own Gateway, the Windows installer fix is already live, sandboxes get a default process budget and the audit follows linked skill folders.
Main Stops Rate-Limit Retries From Snowballing
There is no new tagged release this weekend. npm still points latest at 2026.10.7, extended-stable at 2026.9.34 and beta at 2026.10.10-beta.3, and the official @openclaw account has not posted since Friday afternoon. The main branch, though, took nearly 800 merged pull requests between 5 AM Pacific on Saturday and early Sunday morning. Most were cleanup, including 69 batches removing low-value tests, but a few change what operators will see next, starting with rate limits.
The first, pull request #182954 making rate-limited runs back off instead of failing within seconds, merged at 3:31 PM Pacific on Saturday. Same-model retries waited exactly as long as the provider's hint, and OpenAI tokens-per-minute 429 errors say "try again in ~1s", so under sustained saturation all nine retries fired about a second apart, in lock-step across sessions. Provider timing is now treated as a minimum wait under jittered exponential backoff that caps at 60 seconds for rate limits, and the rate-limit budget grows from 10 to 16 attempts per consecutive outage. Identical failure cards now collapse into one with a repeat count.
That change exposed a second problem, fixed by pull request #183545 stopping rate-limited turns from being relabeled as stalls and rerun, merged at 5:12 AM Pacific on Sunday. The longer retry loop now outlasts the session watchdog's six-minute no-progress window, so the watchdog stopped turns mid-backoff, called them "Reply operation stalled", and stalled-turn recovery queued a rerun straight into the same limit. Stops during an open rate-limit backoff are now marked rate_limited, are not rerun, and show a message saying rate-limit recovery stopped after a number of automatic retries. Other stalls behave as before.
The OpenClaw retry policy documentation already describes the new behavior, including retry.provider.maxRetryDelayMs (default 60 seconds) as the point where a longer provider floor hands off to auth-profile rotation and model fallback. Still open: feature request #182712 for limit-aware model fallback, which asks the fallback chain to skip models on an exhausted provider account.
If you run many agents against one provider organization, these two fixes matter more than any feature this week. Retrying in lock-step every second only deepens a saturation event, and automatic reruns into the same limit made it worse. Until the build ships, configure a fallback model on a different provider account so a real outage has somewhere to go.
Doctor Will Preview Which Automations Lose Access or Pause
On main, scheduled jobs linked to the conversation that created them run with that conversation's authority and pause when it is gone. Pull request #182328 adding a Doctor report for automations that will lose access or pause, by jalehman and merged at 8:23 PM Pacific on Saturday, gives operators a way to see the effect before it happens. openclaw doctor, with or without --fix, now prints a read-only "Scheduled-run access review" under Cron.
The review lists automations that will lose owner-only tools because their creator is no longer an owner, or lose unsandboxed execution because the creating conversation requires a sandbox. It lists automations that will pause at their next run because the conversation was removed, archived or lost its worktree path. It also flags unbound jobs, and jobs whose creating conversation came from 2026.10.6 or earlier and has no stored chat type, so their runs get no conversation memory. The author is explicit that the review writes nothing, repairs nothing and sends nothing, and that there is no openclaw automations bind command yet, so unbound jobs are told to recreate the automation from its conversation.
Run Doctor and read this section before you upgrade a Gateway that carries scheduled work. An automation that silently pauses because someone archived the chat that created it is the kind of failure nobody notices for a week. Treat every line under "will pause" or "unbound" as a ticket, and recreate the important jobs from a conversation you intend to keep.
Owners Can Ask the Agent to Maintain Its Own Gateway
Until now an agent asked by its owner to update or restart the Gateway it runs on would refuse, because the system prompt forbade self-maintenance and the tool lacked restart and cleanup actions. Pull request #182762 letting owners ask the agent to maintain its own Gateway, merged at 11:56 AM Pacific on Saturday, replaces that blanket ban with supervised-maintenance guidance and exposes restart and update.cleanup alongside update.run. Cleanup removes only eligible rollback copies and can be previewed first. Non-owner requests, tool restrictions and the chat restart policy are still enforced.
A related repair covers manual maintenance. Issue #182683 reporting that SIGTERM during doctor --fix left the Gateway stopped on 2026.10.7 describes a macOS Gateway service that stayed down until it was manually bootstrapped. Pull request #182901 restoring the Gateway when Doctor receives SIGHUP makes Doctor restore the Gateway it stopped when interrupted by SIGINT, SIGTERM or a terminal hangup. Its author says the original SIGTERM incident is not proven fixed, and the issue remains open.
Letting an agent restart its own host is a real permission, not just a convenience. Before this ships, decide who counts as an owner on each Gateway. Until the Doctor fixes land, run repairs in a session that will not close halfway, then check the service.
The Windows Installer Fix Is Already Live
One fix reached users without waiting for a release. Issue #183088 reporting the Windows PowerShell installer failing NodeVersion validation showed that the documented iwr -useb https://openclaw.ai/install.ps1 | iex command failed before the installer started, because the optional NodeVersion parameter rejected its own empty value. Pull request #183145 letting the Windows installer run through iex without a NodeVersion, merged at 7:23 PM Pacific on Saturday, changes the validation pattern so an omitted value is accepted while non-empty overrides must still be an exact x.y.z version. When we fetched the script from openclaw.ai on Sunday morning it already carried the corrected pattern, with a last-modified time of 7:50 PM Pacific on Saturday. The OpenClaw install documentation lists the same command.
Security Practice: Sandbox Containers Now Get a Process Budget
Sandboxes without a pidsLimit used to run with no process limit at all
Pull request #182381 defaulting sandbox container PID budgets to 1024, merged at 8:49 AM Pacific on Saturday, fixes a gap where Docker sandbox containers ran with no PID limit when docker.pidsLimit was not set, because the config resolver had no default and emitted no --pids-limit flag. Tool and browser containers now default to 1024 processes. It is on main only.
- The OpenClaw agent sandbox configuration reference now says Docker and Podman tool and browser containers default to a PID limit of 1024, explicit global or per-agent
docker.pidsLimitvalues override it, and shared scope uses only global values. If you are on a current release, setpidsLimitexplicitly today rather than waiting for the default. - Then run
openclaw security audit. Pull request #182407 honoring resolved environment secret provenance stops the audit from flagginghooks.tokenandgateway.auth.passwordas plaintext when they come from${VAR}substitution. The OpenClaw security CLI reference notes that literal secrets and escaped$${VAR}placeholders still produce findings, so a warning that survives is worth fixing.
Skill Card: Audit Linked Skill Folders and Verify What You Installed
The security audit now follows a symlinked workspace skills folder
Pull request #182384 auditing symlinked workspace skill roots, merged at 8:11 AM Pacific on Saturday, fixes openclaw security audit silently skipping nested SKILL.md escapes when workspace/skills is itself a symlink or Windows junction. The audit's first check did not follow the link, so it returned before scanning anything inside. It now reports escapes as skills.workspace.symlink_escape.
Two more checks are worth adding to the same routine. The OpenClaw skills CLI reference documents openclaw skills verify @owner/<slug>, which checks an installed ClawHub skill against the registry it came from (add --card to print its generated Skill Card, which exits non-zero when ClawHub returns a failing decision), and openclaw skills check, which reports missing prerequisites. And pull request #178313 sanitizing terminal escape sequences in skills library output means human-readable library lists now neutralize control sequences hidden in skill metadata, while JSON keeps the original values.
A linked skills folder is a common and sensible way to share skills across agents, and it was also a blind spot in the audit. Once this fix ships, rerun the security audit on every workspace that uses a link, and pair it with skills verify for anything that came from ClawHub. A clean result from a scan that never looked inside proves nothing.
Running scheduled agents at scale?
SEN-X helps teams plan provider fallback for rate limits, review automation access before upgrades, and harden OpenClaw sandboxes and skill folders.
Contact SEN-X →