Bug：容器里已设置 OPENCLAW_NO_RESPAWN=1，OpenClaw gateway 仍会以 PID 1 退出
OpenClaw News 编辑部
OpenClaw 最新又出现了一个很典型、也很容易误判方向的容器问题：gateway 能启动、健康检查能过，但过一会儿还是会退出，即使你已经设置了 OPENCLAW_NO_RESPAWN=1。
现在已知的现象
根据 OpenClaw issue #76239，[email protected] 在非 supervised 容器里作为 PID 1 运行时，可能会在大约 60 到 90 秒后退出。
关键点在于，退出前环境并不是一开始就坏掉：
/readyz返回200- Prometheus metrics 可正常读取
- 在短暂健康窗口内，模型调用还能工作
- 环境里已经设置了
OPENCLAW_NO_RESPAWN=1
这类问题特别容易吃搜索流量，因为用户真正搜索的通常不是“某个 beta 版本回归”，而是“为什么明明健康却自己退出”。
为什么这个问题重要
如果 gateway 作为容器里的 PID 1 意外退出，外部表现会很像基础设施抖动：
- chat 请求开始超时
- 健康检查偶发失败
- 重启现象看起来像容器平台不稳定
- 团队会先把时间花在 Docker、Cloud Run、sandbox 生命周期这些方向上
也就是说，如果不尽快把它识别成版本回归，你很容易在错误方向上浪费几个小时。
这类用户会搜什么
这波高意图搜索词大概率会落在这些组合上：
OPENCLAW_NO_RESPAWN gateway exitsOpenClaw PID 1 container exitsopenclaw 2026.4.30-beta.1 regressionOpenClaw readyz 200 then process exitsOpenClaw container healthy then dies
建议先验证的 5 个点
如果你怀疑自己撞上的是同一个问题，先核对这 5 件事：
- 当前运行版本是不是
2026.4.30-beta.1 - gateway 进程是不是容器内的 PID 1
OPENCLAW_NO_RESPAWN=1是否真的进入了运行时环境- 进程是不是“先健康几十秒，再退出”，而不是一启动就挂
- 跟更早的稳定版本（例如
2026.4.24）相比，行为是否明显不同
当前结论
现阶段更像是版本回归，而不是普通容器配置错误。如果你的实例是“先健康、后退出”，就不要只把它当成 Docker 或编排层问题。
我们会继续跟进上游 issue，一旦官方给出 workaround 或修复版本，再补完整处理路径。
