TUI process consumes 89-99% CPU at idle and during message turns (busy-loop)

Summary

openclaw-tui (the local TUI client started via openclaw chat / openclaw tui --local) sits at 89-99 % CPU for as long as the window is open — both while idle waiting for user input and while a backend turn is in flight. RSS climbs to ~550 MB, VSZ ~2 GB. End-user perceives the chat as "very laggy" even when the underlying claude-cli backend turns complete in normal time.

Version

🦞 OpenClaw 2026.4.26 (be8c246)

• node v24.14.1
• Linux (Hetzner CAX21, ARM64, Debian)

Reproduction

1. openclaw --profile <profile> chat (alias for tui --local)
2. Wait at the empty prompt (no input typed).
3. top -p $(pgrep openclaw-tui) → ~90-99 % CPU.

$ ps -o pid,pcpu,pmem,vsz,rss,etime,comm -p 390376
    PID %CPU %MEM    VSZ   RSS     ELAPSED COMMAND
 390376 89.8  6.9 2055712 550168     04:40 openclaw-tui

CPU stays high regardless of:

• whether a turn is in flight or fully idle
• terminal emulator (Tabby on Windows, plain SSH PTY both reproduce)
• profile in use (dixi, default main, others)

Expected

TUI should be event-driven on stdin / WS messages and use ~0 % CPU at idle.

Observed impact

• Heavy fan / battery drain on the host (Hetzner CAX21 ARM, but also reported by users on local machines)
• Terminal redraws perceived as laggy because the render loop is starving on its own busy-poll
• Ambient claude-cli backend turn duration (median 12 s in our log) feels like 30-60 s to the user because the TUI is unresponsive

Suspected cause

A render / poll loop in the TUI that does not block on a select / event-source. Likely candidates: a setImmediate-style redraw, a polling read on stdin, or a tight loop reading from the agent stream.

Happy to gather more diagnostics (strace, perf top, V8 CPU profile via --inspect) if useful.

Workaround

Avoid chat / tui --local for sessions that should stay open; either:

• use openclaw agent --local --message "..." for one-shot turns, or
• route via Telegram / other channel handlers