OpenClaw merged PR #132784, a targeted CLI fix for operators running openclaw gateway status on constrained machines.
The issue was simple and painful: during the highest-memory phase, the status command could briefly create two full OpenClaw status entry processes while overlapping a running Gateway. On low-memory ARM64 hosts, that overlap could be enough to trigger an out-of-memory kill.
What Changed
The CLI now skips the general warning-suppression respawn only for the exact gateway status command path.
That exactness is the key detail. The PR says root status, gateway call health, automatic CA-certificate startup respawn, and Windows startup behavior keep their existing contracts. The implementation uses OpenClaw's canonical argv parser and requires the exact two-component command path.
No heap limit was changed. No Gateway startup behavior was changed. Status output and RPC behavior are unchanged.
Why This Helps Small Hosts
Plenty of OpenClaw installations run on machines where memory pressure is not theoretical: Raspberry Pi class hosts, small ARM boards, low-cost VPS instances, and older always-on machines.
For those setups, gateway status is exactly the sort of command people automate. It may run from shell scripts, health checks, dashboards, deployment hooks, or cron jobs. A health check that accidentally increases peak memory during a fragile moment can become part of the problem it is meant to observe.
The merged fix keeps the command lightweight by avoiding the duplicate entry process for this exact status path.
Operator Takeaways
If you run OpenClaw on a constrained host, the practical lesson is:
- Keep using
openclaw gateway statusfor health checks. - Expect the same JSON and RPC behavior as before.
- Expect less risk of a transient second OpenClaw process during the status check.
- Do not assume this changes the memory profile of unrelated CLI commands.
The PR also notes that hosts requiring automatic CA-certificate injection still perform the intentionally preserved startup respawn. That behavior has focused test coverage, but it is separate from the gateway status path.
Verification
The evidence is unusually concrete for a CLI memory fix. The pre-fix process regression reproduced two unique OpenClaw entry PIDs; the fixed regression recorded one.
A fresh ARM64 AWS constrained-memory matrix passed 12 out of 12 runs with zero OOM kills. The previous 1 GB no-swap matrix passed only one of two runs and recorded an OOM kill. In the new matrix, 1 GB no-swap passed five of five, 1 GB with 2 GB swap passed two of two, and the 2 GB and 4 GB controls also passed.
The PR reports valid JSON, clean stderr, a live Gateway after every invocation, and one OpenClaw entry process per status check. For users running OpenClaw close to the metal, that is the kind of narrow reliability patch that makes daily operations less brittle.