Summary

Fixes #79947.

The gateway's CLI runner (src/cli/gateway-cli/run.ts) captured the pre-read startup config snapshot once before entering the restart loop and then reused that same snapshot for every iteration. After a SIGUSR1 in-process restart, downstream startup writes (auth bootstrap, plugin auto-enable persistence, control-ui seed) projected the stale snapshot back to disk and silently clobbered any user config written between boot and the restart.

The fix consumes the pre-read snapshot exactly once. Subsequent in-process restart iterations re-read openclaw.json from disk so user writes between restarts survive.

// src/cli/gateway-cli/run.ts
let pendingStartupSnapshot: typeof startupConfigSnapshotRead | undefined =
  startupConfigSnapshotRead;
const startLoop = async () =>
  await runGatewayLoop({
    runtime: defaultRuntime,
    lockPort: port,
    healthHost,
    start: async ({ startupStartedAt } = {}) => {
      const snapshotForThisStart = pendingStartupSnapshot;
      pendingStartupSnapshot = undefined;
      return await startGatewayServer(port, {
        bind,
        auth: authOverride,
        tailscale: tailscaleOverride,
        startupStartedAt,
        ...(snapshotForThisStart ? { startupConfigSnapshotRead: snapshotForThisStart } : {}),
      });
    },
  });

This matches the proposed fix in the issue body — preserve the cold-start optimization on the first iteration, force disk re-read on every iteration after.

Real behavior proof

Behavior or issue addressed: When the OpenClaw gateway runs in an environment without a supervisor marker (OPENCLAW_SYSTEMD_UNIT, INVOCATION_ID, etc. unset — the default in container deployments per src/infra/process-respawn.ts), a SIGUSR1 in-process restart silently overwrites openclaw.json with a snapshot captured at the original boot, dropping any user config written between boot and the restart. Visible to users as "the bot disappeared after I configured it" — bot tokens revert to empty, auth profiles vanish, channels become disabled. See #79947 for the original report including pre/post sha256s and the exact Config overwrite log line.

Real environment tested: Live Docker reproduction on a contributor host (Linux 7.0.3-zen1-2-zen, Arch Linux), Node 24, Docker image node:24-alpine. OpenClaw built locally from this branch (package version 2026.5.8). All SUPERVISOR_HINT_ENV_VARS (OPENCLAW_SYSTEMD_UNIT, INVOCATION_ID, SYSTEMD_EXEC_PID, JOURNAL_STREAM, the launchd hints, OPENCLAW_SERVICE_MARKER, OPENCLAW_SERVICE_KIND) explicitly unset inside the container so detectRespawnSupervisor returns null and the gateway falls through to the in-process restart path documented at src/infra/process-respawn.ts:70 ("container: use in-process restart to keep PID 1 alive"). Gateway invoked with OPENCLAW_ALLOW_ROOT=1 since the container runs as root. Two variants of the same dist/run-D9To-U2i.js were compared: the pre-fix closure shape (BUGGY) and this PR's shape (FIXED). Patch verified to match the source pattern exactly once before swapping.

Exact steps or command run after this patch: Inside node:24-alpine, for each variant of dist/run-D9To-U2i.js: (1) write a minimal openclaw.json with gateway.mode=local, gateway.port=18790, gateway.auth.mode=none. (2) Start the gateway in the background: node dist/index.js gateway run --port 18790 --bind loopback --allow-unconfigured and wait for the [gateway] ready log line (about 6 seconds on the test host). (3) sha256sum /root/.openclaw/openclaw.json to record the baseline. (4) Use node -e to write a restart-required key directly to disk — auth.profiles.repro_79947 = {id, marker: "USER_WROTE_THIS"} and channels.telegram = {enabled: true, botToken: "USER_WROTE_TOKEN"}. (5) sha256sum again to confirm the user write landed. (6) kill -USR1 $GW_PID to trigger the in-process SIGUSR1 restart. (7) sleep 8 for the restart cycle. (8) sha256sum and grep -q USER_WROTE_THIS / grep -q USER_WROTE_TOKEN on /root/.openclaw/openclaw.json to see whether the user write survived. The full driver shell script bind-mounted the source dist/ into /openclaw read-only and copied to a writable /opt/openclaw inside the container.

Evidence after fix: The contributor pasted the full terminal output of the live docker run invocation. Verbatim console output captured from the host (real, non-mock):

BUGGY variant — sha256 + size of openclaw.json from sha256sum and stat -c%s:

disk before user write:  sha=fac21eeb67b3b5f8  size=274
disk after user write:   sha=1a65ebefc47845d8  size=515
sent SIGUSR1; waiting for restart...
disk after restart:      sha=a40253354fc96b38  size=274

Smoking-gun runtime log line printed by the openclaw gateway during the restart iteration (real output captured live, redacted log path is the in-container /root/.openclaw):

2026-05-10T00:52:43.252+00:00 [gateway] signal SIGUSR1 received
2026-05-10T00:52:43.261+00:00 [gateway] received SIGUSR1; restarting
2026-05-10T00:52:43.294+00:00 [gateway] restart mode: in-process restart (container: use in-process restart to keep PID 1 alive)
Config overwrite: /root/.openclaw/openclaw.json
  (sha256 1a65ebefc47845d8495559a2a9f1e9293a866abeb0cf7a80dfdfca4038789fe0
       -> a40253354fc96b38fa5fd39dcd3a7bd3b0d3ffcdac681d56010f5ffdb4137bc9,
   backup=/root/.openclaw/openclaw.json.bak)

Result line emitted by the test driver:

RESULT: auth.profiles.repro_79947 WAS DROPPED (bug present)
RESULT: channels.telegram.botToken WAS DROPPED (bug present)

FIXED variant on the same dist tree, only the closure shape in runGatewayCommand differs:

disk before user write:  sha=2fbd0d8f025788db  size=274
disk after user write:   sha=409d59518ef13671  size=515
sent SIGUSR1; waiting for restart...
disk after restart:      sha=409d59518ef13671  size=515

RESULT: auth.profiles.repro_79947 SURVIVED
RESULT: channels.telegram.botToken SURVIVED

Independent confirmation that the FIXED gateway re-read disk on the restart iteration: the same gateway logged a config validation error against the new auth.profiles.repro_79947 payload that we wrote between boot and SIGUSR1. The buggy gateway never saw that payload because it overwrote the file with the stale snapshot before validation ran. Stack trace excerpt printed live by the gateway runtime:

[gateway] startup failed: Invalid config at /root/.openclaw/openclaw.json.
auth.profiles.repro_79947.provider: Invalid input: expected string, received undefined
auth.profiles.repro_79947.mode: Invalid input (allowed: "api_key", "aws-sdk", "oauth", "token")
auth.profiles.repro_79947: Unrecognized keys: "id", "marker"
    at assertValidGatewayStartupConfigSnapshot (file:///opt/openclaw/dist/server-startup-config--ehPahs8.js:104:8)
    at loadGatewayStartupConfigSnapshot (file:///opt/openclaw/dist/server-startup-config--ehPahs8.js:19:29)
    at async Object.start (file:///opt/openclaw/dist/run-D9To-U2i.js:882:11)
    at async runGatewayLoop (file:///opt/openclaw/dist/run-D9To-U2i.js:403:14)
    at async Object.startLoop (file:///opt/openclaw/dist/run-D9To-U2i.js:875:32)

Observed result after fix: Post-restart sha256 and byte size of openclaw.json match the post-write state exactly (409d59518ef13671 / 515 bytes), versus the BUGGY run where the post-restart sha (a40253354fc96b38) and size (274 bytes) regressed all the way back to the pre-write baseline. The fixed gateway reads openclaw.json from disk on the restart iteration — confirmed both by the surviving content and by the fact that the runtime now surfaces a config validation stack trace for the user-written profile rather than silently overwriting it. Same hardware, same image, same dist tree — only the closure shape in runGatewayCommand differs between the two runs.

What was not tested: End-to-end macOS launchd reproduction. The bug is platform-agnostic — the in-process restart fallback runs the same code on every platform when no supervisor marker is set, per src/infra/process-respawn.ts — but I did not run a live launchd reproduction. I also did not exercise the real openclaw config set CLI flow; the reproduction triggers SIGUSR1 with kill -USR1 and writes the user config directly. The reporter's path used openclaw config set and pairing approve to trigger the same code path; I verified the bug at the SIGUSR1 boundary which is what the fix targets. Three-or-more consecutive in-process restarts in a single gateway run were not exercised live, but the fix is shaped to handle N restarts (snapshot consumed on first, fresh disk read on every iteration after) and the unit regression covers two iterations.

Test plan

• pnpm test src/cli/gateway-cli/run.option-collisions.test.ts — 19/19 pass, including the new regression that verifies startupConfigSnapshotRead is passed only on the first start call within a single runGatewayLoop
• pnpm test src/cli/gateway-cli/run-loop.test.ts src/gateway/server-startup-config.recovery.test.ts src/cli/gateway-cli/run.supervised-lock.test.ts — 36/36 pass
• pnpm check:changed — exit 0 (lint, import-cycle, sidecar-loader, webhook/pairing/account guards)
• pnpm exec oxfmt --check --threads=1 on touched files — clean
• Live Docker reproduction (above) — bug present without the patch, gone with the patch

AI-assisted disclosure

• AI-assisted PR (Claude Haiku 4.5 → Opus 4.7 in Claude Code, on @jimdawdy-hub's machine)
• Human-driven Docker reproduction performed on the contributor's host (not just AI-generated unit tests)
• Author confirms understanding of the closure change and the snapshot consumption semantics
• codex review --base origin/main not run — Codex CLI was not installed on the contributor's machine when this PR was opened. Happy to run it if a maintainer wants that pass before review.
• Will resolve any bot review conversations as they land