openclaw - 💡(How to fix) Fix TUI spins at 100% CPU on 2026.4.29, including --local and --dev local modes [2 comments, 2 participants]

Summary

On OpenClaw 2026.4.29 (a448042), the terminal UI renders its initial frame but never becomes usable. The openclaw-tui child process spins at about 100-110% CPU.

This reproduces in Gateway mode, local embedded mode, and an isolated --dev profile, so it does not appear to be caused only by the running Gateway, gateway auth, or the current user config/session history.

Environment

• OpenClaw: 2026.4.29 (a448042)
• Install kind: npm/pnpm package install
• OS: Linux x64
• Node: 22.x
• Gateway: local loopback using the default OpenClaw port

Reproduction

Gateway mode:

timeout 15s openclaw tui --session diag-codex-tui --history-limit 0

Observed:

• TUI renders:
  • openclaw tui - ws://127.0.0.1:18789 - agent main - session diag-codex-tui
  • connecting | idle
• A child process named openclaw-tui spins at around 100% CPU.

Local embedded mode:

timeout 10s openclaw tui --local --session diag-codex-local --history-limit 0

Observed:

• TUI renders:
  • openclaw tui - local embedded - agent main - session diag-codex-local
  • local ready | idle
• openclaw-tui spins at around 100-110% CPU.

Isolated dev profile:

timeout -s KILL 10s openclaw --dev tui --local --session diag-dev-local --history-limit 0

Observed:

• Same initial TUI frame.
• Same high-CPU openclaw-tui behavior.

Diagnostics Already Run

Following the troubleshooting ladder from the docs:

openclaw status
openclaw status --all
openclaw gateway probe
openclaw gateway status
openclaw doctor
openclaw channels status --probe
openclaw logs --follow

Key results:

• openclaw status reports the local loopback Gateway is reachable with token auth.
• openclaw gateway status reports:
  • systemd service is disabled/stopped
  • a manual Gateway process is listening locally
  • connectivity probe is OK
• openclaw channels status --probe reports the configured channel is running and works.
• openclaw health returns normal health/session output.
• openclaw gateway probe sometimes reports Read probe: failed - timeout, but openclaw tui --local reproduces without using the Gateway, so this does not look like the primary TUI failure.
• openclaw doctor found a stale model auth profile, but local TUI reproduces before any model turn is sent.

Process evidence while the local TUI test is running:

timeout ... openclaw tui --local --session diag-codex-local --history-limit 0
openclaw
openclaw-tui    100-110% CPU

Short strace -p <openclaw-tui-pid> -c sample during the spin:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 40.30    0.088087           4     20554        93 access
 16.62    0.036329           3      9642           read
 15.57    0.034042           4      7256        42 openat
 11.13    0.024318           3      7214           close
  9.74    0.021298           4      4930           getdents64
  2.98    0.006512           3      2092        96 statx

strace -f from startup showed repeated loading/access around OpenClaw modules, typebox, and /tmp/node-compile-cache/openclaw/... entries rather than waiting on a Gateway network response.

Expected Behavior

The TUI should settle into an interactive ready state without a persistent high-CPU openclaw-tui child process.

Actual Behavior

The initial frame renders, but the TUI remains effectively unusable and the openclaw-tui child consumes a full CPU core until killed.

Workarounds Tried

Doctor suggested startup environment variables:

NODE_COMPILE_CACHE=/tmp/openclaw-compile-cache
OPENCLAW_NO_RESPAWN=1

Running TUI with those variables did not resolve the CPU spin.

Non-TUI commands such as openclaw status, openclaw health, and Gateway-backed status/channel probes continue to work.