OpenClaw merged a P0 Gateway reliability fix this morning in PR #153386, targeting a hang that could appear when an agent inherited a model without an explicit runtime pin.
The short version: unpinned agent turns should now complete normally instead of starving other Gateway work. The PR states that affected users do not need a configuration workaround, a new option, or a state migration.
What changed
The bug sat in automatic runtime selection. When repeated preparation resolved an inherited model under another agent's policy, the Gateway could get stuck around lease admission and publication state. That mattered because the failure mode was not just one bad turn. The PR describes health checks and other Gateway requests being starved while the stuck path kept looping.
The repair makes runtime policy resolution happen in the requesting agent's scope before the owner key is derived. Lease admission then reads the exact keyed owner snapshot instead of doing a second snapshot lookup and policy resolution.
The PR also adds a guard for unchanged retries. If a retry cannot observe changed owner or publication state, OpenClaw now surfaces an explicit error instead of silently spinning through the event loop.
Why this matters
This is the kind of fix that matters most to people running OpenClaw as an always-on assistant. A Gateway can tolerate a visible error much better than a silent hang. Silent starvation makes every other check harder: health probes, user turns, hot reloads, and operational diagnostics all become less trustworthy.
The merged change keeps the durable default behavior intact. It does not remove automatic model selection, and it does not force users to pin every agent runtime. Instead, it tightens the ownership boundary so inherited selections are made concrete before admission.
OpenClaw's PR body identifies the root cause as a latent non-idempotence introduced before 2026.9.5, then exposed by the release's restored persisted system-agent fallback for explicit rosters. In plain language: a second normalization could consult a different agent's runtime pin, which is exactly the kind of cross-agent ambiguity a Gateway owner key should avoid.
Validation notes
The evidence package is stronger than a typical small fix:
- Four new regression cases failed against the original production source.
- The registry-borrow cases passed ten executions each after a follow-up assertion.
- 101 focused tests passed across automatic selection, owner selection, Gateway leases, cancelled admission, lifecycle, and hot-reload dispatch.
node scripts/check-changed.mjspassed in full for the selected repository checks.- An isolated dev Gateway test returned
OKwith an inheritedxai/grok-4.6default and no worker runtime pin.
That isolated Gateway proof also recorded 185 successful health probes, with a maximum of 115 ms and low idle CPU during the test window. The PR is careful about scope: the provider endpoint was synthetic, so this is not a claim about external xAI OAuth behavior.
What operators should know
There is no migration or configuration change called out in the PR. The user-facing win is that unpinned inherited runtime paths should fail or complete deterministically instead of trapping the Gateway in a starvation pattern.
For OpenClaw operators who run multiple agents, especially mixed rosters with inherited model defaults, this is a high-priority update to pick up once it lands in the next packaged release.