Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

Upgrading 2026.6.11 → 2026.7.1 refuses gateway readiness whenever startup state migrations emit any warning — including warning-class retained-source findings like "Skipped Memory Core daily ingestion import … because SQLite rows already exist; left legacy source in place" — so a host with long-lived, already-migrated state crash-loops under launchd until rolled back.

Steps to reproduce

1. Run a 2026.6.11 host long enough that Memory Core dreaming legacy JSONs coexist with their already-imported SQLite rows (and/or a Codex session-binding sidecar diverges from newer canonical plugin state — normal after sessions keep running post-import).
2. Update to 2026.7.1 and start the gateway.
3. Startup migrations emit the retained-source warnings, formatStartupMigrationFailure throws OpenClaw startup migrations did not complete cleanly; refusing to report the gateway ready., the process exits 1, and launchd KeepAlive restart-loops it indefinitely.
4. Note that the suggested recovery (openclaw doctor --fix) cannot clear the "SQLite rows already exist" family: the migration deliberately skips the import and leaves the legacy source in place, so the identical warning recurs on every start.

Expected behavior

On 2026.6.11 the same findings were surfaced as doctor warnings while the gateway ran normally. Warning-class retained-source findings (data already migrated; legacy file intentionally left in place; sidecar retained because canonical plugin state is newer) should surface as actionable diagnostics without blocking readiness. Only genuine migration failures/blockers should gate startup.

Actual behavior

Any warning in the startup checkpoint blocks readiness (src/commands/doctor-config-preflight.ts formatStartupMigrationFailure includes warnings alongside blockers). Observed on two unattended update attempts on 2026-07-14 (~10:39–10:50 PDT and ~22:0x PDT, both auto-rolled-back to 2026.6.11 by an external watchdog), and reproduced 2026-07-16 during an attended upgrade: the gateway only reported ready after manually archiving every retained legacy source (4 Memory Core dreaming JSONs, 4 legacy per-agent memory-index sidecars, 12 Codex session-binding sidecars — 8 orphaned, 4 with "canonical plugin state changed").

OpenClaw version

2026.7.1 (also reproduced on the reviewed source build f1226d10d2f over tag 2d2ddc4)

Operating system

macOS (Darwin 25.5.0), Apple Silicon

Install method

git source checkout + pnpm build, gateway run as a launchd service (Node 22.22.3)

Model

n/a — startup/readiness path, model-independent (host default: openai/gpt-5.6-sol)

Provider / routing chain

n/a — local gateway startup, no provider request involved

Additional provider/model setup details

No response

Logs

OpenClaw startup migrations did not complete cleanly; refusing to report the gateway ready.
- Skipped Memory Core daily ingestion import for ~/workspace because SQLite rows already exist; left legacy source in place
- Skipped Memory Core session ingestion import for ~/workspace because SQLite rows already exist; left legacy source in place
- Skipped Memory Core short-term recall import for ~/workspace because SQLite rows already exist; left legacy source in place
- Skipped Memory Core phase signals import for ~/workspace because SQLite rows already exist; left legacy source in place
Run "openclaw doctor --fix" against the mounted state/config, then restart the container.

After clearing those and restarting, the gate then failed on the next warning family:

- Left Codex binding sidecar in place because canonical plugin state changed at session-key:<agent-a>:<hash>: ~/.openclaw/agents/<agent-a>/sessions/<uuid>.jsonl.codex-app-server.json
- Left Codex binding sidecar in place because canonical plugin state changed at session-key:<agent-b>:<hash>: ~/.openclaw/agents/<agent-b>/sessions/<uuid>.jsonl.codex-app-server.json

(“canonical plugin state changed” is itself the migration correctly preferring the newer canonical row — yet it still blocks readiness.)

Screenshots, recordings, and evidence

Launchd reached repeated starts with exit code 1 and nothing bound the gateway port until the legacy sources were archived; the identical state ran healthy on 2026.6.11 immediately before and after (rollback). Found while adopting 2026.7.1 to pick up #101505; related field reports from this host: #96834 (comment), #107389.

Impact and severity

Gateway is fully unavailable (all channels down) while crash-looping; unattended/auto-updates to 2026.7.1 fail permanently on any host with pre-existing migrated state and require external rollback automation or manual state surgery. Workaround that worked: back up and archive the retained legacy source files (Memory Core dreaming JSONs, legacy memory-index sidecars, stale Codex binding sidecars), then restart — but the affected files are runtime-managed and users have no documented way to know which files to move.