Best possible solution:

Land one narrow consume-once startup snapshot fix with the regression test, then close the linked bug after merge and close the duplicate fix PR as superseded.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main's source path shows the stale pre-read snapshot is passed into every in-process restart start, and the linked bug plus PR proof describe a concrete SIGUSR1/config-write path; I did not run an independent live container repro in this read-only pass.

Is this the best way to solve the issue?

Yes. Consuming the CLI pre-read snapshot once is the narrow owner-boundary fix: first boot keeps the startup optimization, later in-process restarts omit initialSnapshotRead and force the gateway startup loader to read disk again.

What I checked:

• Protected label: Live PR metadata shows this PR is open, non-draft, mergeable, and labeled maintainer, which blocks conservative cleanup closure even when the change looks correct. (fcc6ebc2bb94)
• Current-main root cause: Current main captures startupConfigSnapshotRead before runGatewayLoop and passes it into every startGatewayServer call made by the run loop, so the same pre-read snapshot is available on later in-process starts. (src/cli/gateway-cli/run.ts:790, 35ceba0e4e6a)
• Snapshot contract: loadGatewayStartupConfigSnapshot uses initialSnapshotRead when supplied and only reads openclaw.json from disk when it is absent, matching the linked bug's stale-snapshot failure mode. (src/gateway/server-startup-config.ts:66, 35ceba0e4e6a)
• In-process restart path: The run loop falls back to in-process restart and resolves the restart loop instead of spawning a fresh process when respawn is unavailable, so later iterations reuse the same closure from runGatewayCommand. (src/cli/gateway-cli/run-loop.ts:253, 35ceba0e4e6a)
• Patch behavior: The PR changes the run-loop closure to move startupConfigSnapshotRead through a consume-once variable and adds a regression test asserting the first start receives the snapshot while the second does not. (src/cli/gateway-cli/run.ts:787, fcc6ebc2bb94)
• Related work: Search found the linked open bug, this PR, the earlier closed unmerged attempt, and another open PR with the same central fix at fix(gateway): re-read config on in-process restart instead of replaying stale snapshot #80041.

Likely related people:

• steipete: The startup snapshot handoff was introduced in commit 5980040, and recent path history shows repeated gateway startup/config work by this author. (role: introduced behavior and frequent adjacent contributor; confidence: high; commits: 598004089454, 0ee52e940547, e651809084a1; files: src/cli/gateway-cli/run.ts, src/gateway/server-startup-config.ts, src/cli/gateway-cli/run.option-collisions.test.ts)
• vincentkoc: Recent commits on src/cli/gateway-cli/run.ts cover CLI/gateway startup guidance and the current shallow blame attributes the surrounding run-loop block to this author in the checked-out main snapshot. (role: recent area contributor; confidence: medium; commits: be1c38e692f2, 346e327586ee, ad943ec30c74; files: src/cli/gateway-cli/run.ts)
• shakkernerd: Recent history on server-startup-config.ts includes plugin metadata and config snapshot work directly adjacent to the snapshot reuse contract. (role: adjacent startup-config contributor; confidence: medium; commits: 5a72378b2797, d62cc59388b5, fd6c9fc7f5f6; files: src/gateway/server-startup-config.ts)

Remaining risk / open question:

• Another open PR, fix(gateway): re-read config on in-process restart instead of replaying stale snapshot #80041, appears to solve the same linked bug, so maintainers should pick one branch rather than merge both.
• One Critical Quality check was still in progress when inspected, so final merge should wait for exact-head CI completion.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 35ceba0e4e6a.