openclaw - 💡(How to fix) Fix TUI: stuck on 'connecting | idle', spins at ~98% CPU, never establishes session [2 comments, 2 participants]

Summary

TUI gets stuck on connecting | idle indefinitely and never establishes a session, even when the gateway is healthy and responding normally on other surfaces (webchat, Telegram).

Steps to Reproduce

1. Gateway is running and healthy (openclaw gateway status ok, webchat responding)
2. Run openclaw tui
3. TUI shows:

   openclaw tui - ws://127.0.0.1:18789 - agent main - session main
   connecting | idle
   agent main | session main | unknown | tokens ?

4. Input prompt is frozen — cannot type anything
5. Process is at ~98% CPU (ps aux | grep openclaw-tui)
6. After ~1m 38s TUI exits on its own with no error message

Expected Behavior

TUI connects, session establishes, prompt is interactive.

Actual Behavior

• TUI shows connecting | idle and never transitions to connected state
• Input is completely frozen
• Process spins at ~98% CPU
• Eventually times out and exits silently (~98s)
• If retried multiple times, stale TUI processes accumulate (each at ~98% CPU), further degrading the system

Gateway Logs Evidence

Event loop saturated during TUI attempts

Gateway liveness warnings show sustained saturation while TUI was stuck:

2026-05-01T16:14:32 liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu
  eventLoopDelayP99Ms=6316.6 eventLoopDelayMaxMs=7268.7 eventLoopUtilization=0.999 cpuCoreRatio=0.95 queued=3

2026-05-01T16:18:46 liveness warning: reasons=event_loop_delay,event_loop_utilization
  eventLoopDelayP99Ms=7537.2 eventLoopDelayMaxMs=8447.3 eventLoopUtilization=0.999 queued=3

2026-05-01T16:20:52 liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu
  eventLoopDelayP99Ms=6534.7 eventLoopDelayMaxMs=7109.3 eventLoopUtilization=1 queued=2

2026-05-01T16:23:10 liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu
  eventLoopDelayP99Ms=7331.6 eventLoopDelayMaxMs=8178.9 eventLoopUtilization=0.999 queued=3

core-plugin-tools baseline latency

Every single agent run (even with zero MCP servers configured) takes 6–9 seconds just in the core-plugin-tools prep stage:

[trace:embedded-run] totalMs=31003 stages=core-plugin-tools:7264ms, system-prompt:5516ms, stream-setup:8905ms
[trace:embedded-run] totalMs=23548 stages=core-plugin-tools:6640ms, system-prompt:5363ms, stream-setup:5112ms
[trace:embedded-run] totalMs=20244 stages=core-plugin-tools:7718ms, system-prompt:5082ms, stream-setup:4695ms
[trace:embedded-run] totalMs=46764 stages=core-plugin-tools:9540ms, system-prompt:10323ms, stream-setup:4926ms
[trace:embedded-run] totalMs=35728 stages=core-plugin-tools:8977ms, system-prompt:8532ms, stream-setup:7566ms
[trace:embedded-run] totalMs=22206 stages=core-plugin-tools:8870ms, system-prompt:5841ms, stream-setup:5178ms
[trace:embedded-run] totalMs=21576 stages=core-plugin-tools:8172ms, system-prompt:5249ms, stream-setup:5546ms

MCP config at time of logging: mcp.servers: {} (empty — zero MCP servers). The ~7–9s core-plugin-tools latency appears to be a baseline cost unrelated to MCP load.

sessions.list response times elevated

WebSocket API was also slow during TUI connect attempts:

⇄ res ✓ sessions.list 1349ms
⇄ res ✓ sessions.list 1317ms
⇄ res ✓ sessions.list 1474ms
⇄ res ✓ sessions.list 1522ms

Hypothesis

The TUI session handshake requires a timely sessions.list or similar response from the gateway. When the event loop is blocked by concurrent core-plugin-tools initializations (each taking 7–9s), the TUI's WS handshake times out. The TUI then spins at 100% CPU rather than exiting cleanly.

Even with zero MCP servers configured, the core-plugin-tools baseline latency is high enough to cause TUI connect failures under normal conversational load.

Environment

• OpenClaw: 2026.4.29 (a448042)
• OS: macOS Darwin 25.4.0 (arm64)
• Terminal: iTerm2
• Node: v25.5.0
• MCP servers at time of failure: none (mcp.servers: {})