openclaw - 💡(How to fix) Fix 2026.4.29 TUI stays on connecting and spins CPU while gateway is healthy [1 comments, 2 participants]

Summary

After upgrading OpenClaw to 2026.4.29 on macOS, openclaw tui --session main stayed visually stuck on connecting | idle even though the gateway was healthy and the TUI process had an established WebSocket connection. The openclaw-tui child process burned about 100% CPU until killed. Rolling back to 2026.4.27 restored normal TUI startup.

Environment

• macOS on Apple Silicon
• Shell: fish/zsh
• Node used by OpenClaw wrapper: /opt/homebrew/opt/node@24/bin/node (v24.15.0)
• Broken version: OpenClaw 2026.4.29 (a448042)
• Working rollback version: OpenClaw 2026.4.27 (cbc2ba0)
• Gateway bind/port: 127.0.0.1:18789

Symptoms

• openclaw tui --session main rendered the initial TUI frame, then stayed at:

connecting | idle
agent main | session main | unknown | tokens ?

• openclaw-tui sat around ~100% CPU.
• lsof showed an established TCP/WebSocket connection between the TUI process and the gateway on 127.0.0.1:18789.
• Gateway health/status calls succeeded while the TUI was stuck.
• Non-TUI agent calls worked, for example openclaw agent --session-id main --message ... --json returned successfully.

Diagnostics

Gateway was not the blocker:

• openclaw gateway call health --timeout 10000 --json returned "ok": true.
• openclaw gateway status --deep showed the LaunchAgent loaded, runtime running, connectivity probe OK, and admin-capable.
• Dashboard returned HTTP 200.

Profiling the stuck openclaw-tui process on 2026.4.29 pointed at plugin/runtime dependency path resolution, with hot frames around functions such as:

• normalizePluginLoaderAliasMapForJiti
• collectRuntimePackageWildcardImportTargets
• isPathInside
• resolve from node:path

and bundled files similar to:

• boundary-path-*.js
• sdk-alias-*.js
• loader-*.js

The generated runtime dependency directory for 2026.4.29 had also grown very large compared to prior versions:

~/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-...   ~926M
~/.openclaw/plugin-runtime-deps/openclaw-2026.4.29-...   ~3.9G after rebuild

Before rebuild, the 2026.4.29 runtime dependency directory was about 9.4G. Quarantining and rebuilding it with openclaw doctor --fix reduced the size but did not fix the TUI spin.

Things Tried

• Fixed config permissions from 644 to 600.
• Removed stale disabled plugin config stubs for acpx and memory-core from plugins.allow / plugins.entries. This removed config warnings but did not fix the TUI hang.
• Restarted gateway and verified gateway health.
• Rebuilt plugin runtime deps with openclaw doctor --fix.
• Tried openclaw tui --local --session main; it reached local ready | idle but still spun CPU.
• Tried --history-limit 0; still spun.
• Tried updating nested @mariozechner/pi-tui from 0.70.6 to 0.71.1; still spun.

Workaround

Rolling back to 2026.4.27 fixed the TUI. After rollback, I also had to quarantine the stale generated plugin registry because it referenced a 2026.4.29 bundled plugin manifest that no longer existed:

~/.openclaw/plugins/installs.json

Then openclaw doctor --fix rebuilt the plugin registry for 2026.4.27. A fresh openclaw tui --session main then reached:

gateway connected | idle

and CPU returned to idle.

Expected

openclaw tui --session main should connect promptly when the gateway is healthy and the WebSocket is established, without pegging CPU in plugin runtime path resolution.

Actual

On 2026.4.29, the TUI appeared stuck at connecting | idle and burned CPU even though the gateway and WebSocket connection were healthy.