Summary

The OpenClaw Gateway process consumes 100% CPU from the moment it starts and never drops. Memory usage is 724MB (peak 900MB). The node.list RPC call takes 21-35 seconds, and sessions.list takes 2-5 seconds. The Web UI (openclaw-control-ui) polls these endpoints every 2-3 seconds, causing request pileup and the Gateway being permanently stuck at 100% CPU.

Restarting the Gateway does not help — CPU hits 100% immediately after startup.

Environment

OpenClaw: 2026.4.29 (a448042)
Node: v24.15.0
OS: macOS 26.4.1 (ARM64, Apple Silicon)
Gateway PID: 5276 → 9075 (after restart)
Plugins: feishu, llm-task, memclaw
MCP servers: mempalace (Python), context-mode (npx)

Evidence

CPU from startup

$ ps -p 9075 -o %cpu,comm
99.9%  node

node.list latency (right after restart)

22:16:25  node.list  21,005ms
22:16:49  node.list   4,228ms
22:17:51  node.list   5,281ms
22:18:21  node.list  14,074ms

sessions.list latency

22:15:41  sessions.list  3,183ms
22:16:09  sessions.list  4,840ms
22:16:12  sessions.list  2,990ms
22:16:24  sessions.list  3,011ms

Memory

Physical footprint: 724.0M
Physical footprint (peak): 900.8M

Gateway sample (CPU profile)

777 samples on main thread, all in:
  uv_run → uv__io_poll → uv__stream_io → OnUvRead → JS callback

Network connections

183.240.229.82:443   — Feishu API (4 connections)
111.13.213.62:443    — XiaomiMimo API (2 connections)
localhost:18789      — WebSocket (Web UI)
6 unix sockets       — MCP server pipes

Web UI reconnection pattern

21:19:34  connected  b859...
21:25:56  disconnected  (6 minutes)
21:26:29  connected  48b3...  (33s later)
21:53:47  disconnected  (27 minutes)
21:53:48  connected  1329...  (1s later)
22:00:20  disconnected + immediate reconnect

Analysis

1. node.list is the bottleneck — 21-35s per call, should be <100ms
2. Not a state bloat issue — happens immediately after fresh restart
3. Web UI is a victim, not the cause — requests pile up because each takes seconds
4. Plugin initialization — feishu and llm-task each load 30 bundled runtime deps at startup
5. Possibly related to MCP server startup — 7 MCP processes (3 Python + 4 Node) spawn during init

Comparison with existing issues

• TUI processes peg 100% CPU each and survive terminal close, eating all RAM #75289 / TUI process consumes 89-99% CPU at idle and during message turns (busy-loop) #75137: TUI processes at 100% CPU — different process (TUI vs Gateway)
• Gateway lazy-spawns duplicate stdio MCP children with identical ppid+config (memory + CPU leak) #75621: Duplicate MCP children — we see 7 MCP processes but not confirmed duplicates
• This issue: Gateway itself at 100% CPU from startup, with extreme node.list latency

Steps to reproduce

1. Start Gateway: openclaw gateway start
2. Open Web UI (openclaw-control-ui)
3. Observe CPU immediately hits 100%
4. Check gateway.log for node.list latency >20s

Expected behavior

Gateway should idle at <5% CPU when no active LLM requests are in flight.