OpenClaw merged a P1 Gateway recovery fix late Tuesday in PR #161294, titled fix(gateway): keep manual recovery when restart triage declines.
The bug showed up in foreground Gateway runs after an in-process restart hit a refused configuration and automatic triage declined to take over. Instead of staying available for signal-based manual recovery, the process could exit.
For operators running OpenClaw directly in a terminal or unmanaged process, that distinction matters. If the process exits, the recovery surface is gone. If it stays alive with the right instructions, the operator can still intervene.
The New Behavior
When restart triage declines, OpenClaw now keeps the foreground process alive and prints the refusal details, the relevant Doctor command, and the applicable recovery step.
Unmanaged runs also remain available for manual recovery after an admitted triage failure or a failed startup retry. Recorded supervisors keep the nonzero-exit recovery path, and Windows or external supervisor setups receive their own restart instructions.
The fix separates outcomes that previously looked too similar:
- A declined handoff is not treated as a terminal restart result.
- A confirmed admitted triage failure can still follow its intended path.
- A successful triage gets one startup retry after confirmed cleanup.
- Supervisor identity decides whether exiting is actually the recoverable behavior.
The PR also documents the exit contract in docs/cli/triage.md, which should help operators and future maintainers reason about the difference between foreground, unmanaged, and supervised Gateway recovery.
Why It Matters
Gateway restart recovery is one of those paths nobody thinks about when everything is healthy. When configuration breaks during restart, it becomes the whole story.
The safest behavior depends on how the Gateway is being run. A supervised service may need to exit so the supervisor can restart it or record failure correctly. A foreground process often needs the opposite: stay alive, show the refusal, and keep the operator's manual recovery path intact.
PR #161294 makes that split more explicit. It avoids turning a declined automatic recovery path into an accidental process exit for foreground runs.
Proof From The Maintainers
The PR reports that the baseline failed four recovery cases because the loop terminated. A real continuation test also failed because an admitted failure was returned as declined.
The patched version was tested through pnpm openclaw gateway run on Linux with isolated state and a free loopback port. The proof showed the Gateway serving HTTP 200 before a refused gateway.bind change, then staying alive afterward with no HTTP listener while the process remained available for recovery.
There are no schema, dependency, storage, or updater rollback changes in this PR. It is a targeted recovery-contract fix, but an important one: when automatic triage declines, a foreground OpenClaw Gateway should leave the human operator with a live recovery handle.