Bug: OpenClaw gateway exits as PID 1 in containers even with OPENCLAW_NO_RESPAWN=1
OpenClaw News Editorial Desk
A fresh OpenClaw regression is now hitting container-based installs: the gateway starts, becomes healthy, and then exits anyway, even when OPENCLAW_NO_RESPAWN=1 is already set.
What is happening
According to OpenClaw issue #76239, [email protected] can exit after roughly 60 to 90 seconds when running as PID 1 inside a non-supervised container.
The report is notable because the environment is not obviously broken before the exit:
/readyzreturns200- Prometheus metrics are available
- model calls still work during the short healthy window
OPENCLAW_NO_RESPAWN=1is already present
That combination makes this a strong search-intent topic because operators will often search for the symptom, not the release note.
Why this matters
If your gateway is the first process in a container and exits unexpectedly, the failure can look random from the outside:
- chat requests begin timing out
- health probes start flapping
- restarts look like infra instability instead of an app regression
- teams may waste time debugging Docker, Cloud Run, or sandbox lifecycle settings first
In practice, this is exactly the kind of issue that can absorb hours unless you quickly connect it to the current beta regression window.
Search terms this maps to
People troubleshooting this failure are likely to search combinations like:
OPENCLAW_NO_RESPAWN gateway exitsOpenClaw PID 1 container exitsopenclaw 2026.4.30-beta.1 regressionOpenClaw readyz 200 then process exitsOpenClaw container healthy then dies
What to verify next
If you suspect you are hitting the same bug, verify these points first:
- Confirm the running version is
2026.4.30-beta.1 - Confirm the gateway process is PID 1 in the container
- Confirm
OPENCLAW_NO_RESPAWN=1is actually present in the runtime environment - Check whether the process exits after a short healthy period instead of failing immediately
- Compare behavior against an earlier known-good version such as
2026.4.24
Current takeaway
This currently looks more like a release regression than a normal container misconfiguration. If your install is healthy for a short window and then dies anyway, stop treating it as only a Docker or orchestration problem.
We will follow the upstream issue and publish the confirmed workaround or fix path as soon as it lands.
