Summary
PR #3 (8735910, merged 2026-08-31) bumped the OpenClaw item from 2026.7.1 to 2026.8.1 and rewrote the component's runtime contract along with it. It merged with its own verification checklist incomplete: the devcontainer has no container runtime, so none of the change was exercised against a running image.
This tracks reverting the item to 2026.7.1 — the last state verified live — until that verification can be done on a host with Docker.
What #3 changed
- Image pin
ghcr.io/openclaw/openclaw:2026.7.1 → 2026.8.1
- Readiness probe
/readyz → /startupz
- Gateway exec gained
--bind lan --port 18789
- Seven container-side paths pinned as
envVars (HOME, OPENCLAW_HOME, OPENCLAW_STATE_DIR, OPENCLAW_CONFIG_DIR, OPENCLAW_CONFIG_PATH, OPENCLAW_WORKSPACE_DIR, OPENCLAW_GATEWAY_PORT)
- Listing: version string, plus notes on redeploy-volatile tooling and on background model calls
Why revert rather than fix forward
#3's own "Not verified" section lists what never ran, and it covers every behavioural claim in the change:
- Live smoke test against
2026.8.1 — including whether config set still exits 0, which the renewed "re-verified against 2026.8.1" comment now asserts from research rather than an observed run.
- Negative control proving the bind is load-bearing — unset
gateway.bind, drop --bind lan, confirm the port is unreachable.
- Control UI check, which would settle whether the listing's standing "messaging-channel onboarding requires the interactive CLI" caveat still holds.
2026.7.1 → 2026.8.1 in-place upgrade on a shared volume. This release carries two breaking migrations (OpenProse plugin removal, codex/* → openai/* model refs).
That last item is why this is a revert and not a follow-up. Existing deployments cross those migrations in place, against volumes already holding user config, session history, and the OAuth-token encryption key. Upstream's stated behaviour is that a startup migration which cannot repair safely exits rather than reporting healthy, and recovery is a manual doctor --fix run against the same mounts — which a user deploying from this catalog has no obvious way to invoke. The failure mode is a dead deployment the user cannot fix from the platform UI.
The probe and bind changes are plausible readings of upstream's documentation, and may well be correct. But they were merged on documentation alone, and they are precisely the two things standing between the platform edge and a deployment being marked healthy. Shipping them unexercised alongside an unexercised major-version bump concentrates too much unverified change in the one item's admission path.
Reverting restores the pin that was verified live. The analysis in #3 is good and stands on the record for a re-land.
Scope
Full revert of 8735910. Both files return byte-for-byte to their pre-#3 state (git diff 8735910^ -- items/openclaw/ is empty). No other item is touched.
Re-land criteria
On a host with a container runtime:
2026.8.1 boots, config set exits 0, and the Control UI is reachable through a non-loopback bind.- Negative control confirms
--bind lan is load-bearing.
2026.7.1 → 2026.8.1 in-place upgrade on a populated volume survives both breaking migrations.- Messaging-channel onboarding caveat re-checked against the running Control UI, then kept or softened on evidence.
Summary
PR #3 (
8735910, merged 2026-08-31) bumped the OpenClaw item from2026.7.1to2026.8.1and rewrote the component's runtime contract along with it. It merged with its own verification checklist incomplete: the devcontainer has no container runtime, so none of the change was exercised against a running image.This tracks reverting the item to
2026.7.1— the last state verified live — until that verification can be done on a host with Docker.What #3 changed
ghcr.io/openclaw/openclaw:2026.7.1→2026.8.1/readyz→/startupz--bind lan --port 18789envVars(HOME,OPENCLAW_HOME,OPENCLAW_STATE_DIR,OPENCLAW_CONFIG_DIR,OPENCLAW_CONFIG_PATH,OPENCLAW_WORKSPACE_DIR,OPENCLAW_GATEWAY_PORT)Why revert rather than fix forward
#3's own "Not verified" section lists what never ran, and it covers every behavioural claim in the change:
2026.8.1— including whetherconfig setstill exits 0, which the renewed "re-verified against 2026.8.1" comment now asserts from research rather than an observed run.gateway.bind, drop--bind lan, confirm the port is unreachable.2026.7.1→2026.8.1in-place upgrade on a shared volume. This release carries two breaking migrations (OpenProse plugin removal,codex/*→openai/*model refs).That last item is why this is a revert and not a follow-up. Existing deployments cross those migrations in place, against volumes already holding user config, session history, and the OAuth-token encryption key. Upstream's stated behaviour is that a startup migration which cannot repair safely exits rather than reporting healthy, and recovery is a manual
doctor --fixrun against the same mounts — which a user deploying from this catalog has no obvious way to invoke. The failure mode is a dead deployment the user cannot fix from the platform UI.The probe and bind changes are plausible readings of upstream's documentation, and may well be correct. But they were merged on documentation alone, and they are precisely the two things standing between the platform edge and a deployment being marked healthy. Shipping them unexercised alongside an unexercised major-version bump concentrates too much unverified change in the one item's admission path.
Reverting restores the pin that was verified live. The analysis in #3 is good and stands on the record for a re-land.
Scope
Full revert of
8735910. Both files return byte-for-byte to their pre-#3 state (git diff 8735910^ -- items/openclaw/is empty). No other item is touched.Re-land criteria
On a host with a container runtime:
2026.8.1boots,config setexits 0, and the Control UI is reachable through a non-loopback bind.--bind lanis load-bearing.2026.7.1→2026.8.1in-place upgrade on a populated volume survives both breaking migrations.