Hi! I found a reproducible issue with the Home Assistant Add-on that may be worth handling automatically.
Environment
- Home Assistant OS
- OpenClaw Assistant Add-on v0.5.80
- OpenClaw was manually updated to 2026.6.11 from inside the add-on using
openclaw update.
- Everything worked correctly afterward: Telegram, WhatsApp, and the Gateway.
What happened
After updating Home Assistant OS only, while the OpenClaw add-on itself was not updated, the add-on restarted with the bundled OpenClaw CLI 2026.6.10 instead of the manually updated 2026.6.11.
The persistent configuration had already been written by 2026.6.11 (meta.lastTouchedVersion), so the bundled 2026.6.10 binary refused to start the Gateway.
The result was:
- Telegram stopped responding.
- WhatsApp stopped responding.
- Gateway became unreachable:
ECONNREFUSED 127.0.0.1:18789.
curl http://127.0.0.1:18789 failed.openclaw gateway refused to start because the config had been written by a newer version.
Running:
immediately upgraded the runtime back to 2026.6.11, updated the plugins, and everything started working again.
Root cause
The manually updated OpenClaw runtime does not survive an add-on rebuild/restart caused by a Home Assistant OS update. The add-on falls back to the bundled CLI version, while the persistent config under /config/.openclaw remains on the newer format.
This creates a version mismatch:
- Runtime: older
- Config: newer
The Gateway correctly refuses to start, but from a user perspective it looks like OpenClaw has simply stopped working.
Suggested improvement
It would be great if the add-on could automatically detect this situation during startup.
For example:
- Compare the bundled CLI version with
meta.lastTouchedVersion.
- If the bundled CLI is older:
- automatically restore the previously installed OpenClaw version, if possible, or
- automatically run
openclaw update, or
- at minimum present a clear startup warning explaining exactly what happened and how to recover.
This would prevent a Home Assistant OS update from leaving users with a non-functional Gateway after they previously updated OpenClaw manually.
I was able to reproduce this behavior consistently.
Hi! I found a reproducible issue with the Home Assistant Add-on that may be worth handling automatically.
Environment
openclaw update.What happened
After updating Home Assistant OS only, while the OpenClaw add-on itself was not updated, the add-on restarted with the bundled OpenClaw CLI 2026.6.10 instead of the manually updated 2026.6.11.
The persistent configuration had already been written by 2026.6.11 (
meta.lastTouchedVersion), so the bundled 2026.6.10 binary refused to start the Gateway.The result was:
ECONNREFUSED 127.0.0.1:18789.curl http://127.0.0.1:18789failed.openclaw gatewayrefused to start because the config had been written by a newer version.Running:
immediately upgraded the runtime back to 2026.6.11, updated the plugins, and everything started working again.
Root cause
The manually updated OpenClaw runtime does not survive an add-on rebuild/restart caused by a Home Assistant OS update. The add-on falls back to the bundled CLI version, while the persistent config under
/config/.openclawremains on the newer format.This creates a version mismatch:
The Gateway correctly refuses to start, but from a user perspective it looks like OpenClaw has simply stopped working.
Suggested improvement
It would be great if the add-on could automatically detect this situation during startup.
For example:
meta.lastTouchedVersion.openclaw update, orThis would prevent a Home Assistant OS update from leaving users with a non-functional Gateway after they previously updated OpenClaw manually.
I was able to reproduce this behavior consistently.