bug: HAOS Add-on — Multiple stacking issues causing 7–16 min first response delays on HA Green

[jjuarez2534]

Pre-flight checks

• I updated to the latest add-on version and restarted it.
• I checked the docs/troubleshooting section first.

What happened?

Running OpenClaw as a HAOS add-on on HA Green (Rockchip RK3566, 4GB RAM). Experiencing three separate issues that stack on startup and cause 7–16 minute delays on first interaction after startup.
Environment:

Hardware: HA Green (Rockchip RK3566, 4GB RAM)
OpenClaw version: 2026.4.26
HAOS — read-only filesystem
IPv6 disabled at HA network level, Force IPv4 DNS Order ON, NODE_OPTIONS=--dns-result-order=ipv4first

Issue 1 — CLI Gateway Connection Failure (setRawMode EIO):
EMBEDDED FALLBACK: Gateway agent failed; running embedded agent: Error: setRawMode EIO
CLI cannot connect to the running gateway and falls back to embedded agent. Fires multiple times before resolving. Appears to be a HAOS terminal limitation — is this confirmed?
Issue 2 — IPv6 Socket Timeout:
Despite all IPv4 settings enabled, 3x IPv6 fallbacks fire on every startup cycle before settling on IPv4. HAOS read-only filesystem blocks sysctl so IPv6 cannot be disabled at kernel level.
Issue 3 — OpenRouter Pricing Fetch Timeout:
60-second stall on every startup while fetching OpenRouter pricing. All three issues stack sequentially, compounding the delay.
Community guidance so far: Discord community (manjax, groff, Dr. Mann) recommends Docker on separate x86 hardware as the correct deployment for reliable performance, with 4.23 confirmed stable. Posting here to confirm whether any HAOS-specific fix exists before switching deployment entirely.

What did you expect to happen?

OpenClaw add-on should start and be ready to respond within 60–90 seconds of the HA add-on starting, consistent with Docker deployment performance reported by the community.

Steps to reproduce

1. Install OpenClaw add-on on HAOS (HA Green, Rockchip RK3566)
2. Set gateway token, configure IPv4 DNS order, disable IPv6 at HA network level
3. Start the add-on
4. Observe 60-second stall on OpenRouter pricing fetch, followed by repeated IPv6 fallbacks, followed by setRawMode EIO CLI gateway connection failures
5. First response delayed 7–16 minutes after add-on start

Add-on version

0.5.70

OpenClaw version (if known)

2026.4.26

Access mode

custom

Relevant add-on configuration (redacted)

model: anthropic/claude-sonnet-4-6
NODE_OPTIONS: --dns-result-order=ipv4first
IPv6: disabled at HA network level
Force IPv4 DNS Order: ON
Gateway token: [redacted]

Add-on logs

Log shows repeated IPv6 fallbacks on startup, setRawMode EIO errors on CLI connection, and 60-second OpenRouter pricing fetch stall. Available on request.

Additional context

Hardware: HA Green (Rockchip RK3566, 4GB RAM, HAOS read-only filesystem).
Network: Arris S33 modem + TP-Link Deco mesh, DuckDNS + Let's Encrypt for remote access.
Community context: OpenClaw Discord confirms Docker on separate x86 hardware resolves all three issues. 4.23 flagged as stable version by multiple community members. Posting here to confirm whether any HAOS-specific fix exists before switching deployment.

[techartdev]

@jjuarez2534 Hey! Thanks for the detailed report!

So here's what I see and suggest:

• You are on add-on OpenClaw 2026.4.26, which is in the version window several users have reported as slow/unstable on low-resource systems.
• The current add-on image has moved to OpenClaw 2026.5.2, so please upgrade the add-on and confirm the startup log shows 2026.5.2.
• force_ipv4_dns is already the intended HAOS-side mitigation for IPv6 fallback behavior. HAOS has a read-only host filesystem, so the add-on should not try to apply kernel-level IPv6 sysctl changes. You can enable it in Configuration.
• setRawMode EIO looks like an OpenClaw CLI fallback + HAOS/ttyd terminal limitation. It is noisy, but it does not necessarily mean the gateway is unhealthy.
• The OpenRouter pricing-fetch stall and event-loop/liveness warnings appear to be upstream OpenClaw runtime behavior, not something the add-on can safely patch without a narrower root cause.

If this still reproduces after upgrading to the latest add-on/OpenClaw 2026.5.2+, please attach the startup log plus any stability bundle from /config/.openclaw/logs/stability/, and include enabled channels/providers such as Telegram and OpenRouter.

[jjuarez2534]

Updated to add-on 0.5.72 today. Startup log still shows OpenClaw core v2026.4.26, not 2026.5.2. Polling stalls persist at ~138s per cycle. Ping to api.telegram.org = 135-148ms. Messages eventually get through with 10-12 minute delays.
I can see PR #129 is open to bump to 2026.5.3-1 (add-on 0.5.73). Waiting for that to merge. Will attach stability bundle after updating.