Summary
Two related issues that together cause eventLoopUtilization=1 and cpuCoreRatio=1.5+, making the gateway unresponsive (cron tool timeouts, slow responses).
Issue 1: Temp files not cleaned up after atomic writes
.tmp files accumulate indefinitely after atomic writes:
~/.openclaw/devices/paired.json.*.tmp
~/.openclaw/cron/jobs-state.json.*.tmp
~/.openclaw/update-check.json.*.tmp
After ~2 weeks of runtime: 150+ paired.json temps, 300+ cron state temps, 67+ update-check temps.
These should be deleted after the atomic rename succeeds. The accumulation causes significant I/O overhead.
Issue 2: node.list probe takes ~2 seconds per call, Control UI polls continuously
With no nodes paired, node.list still performs a 2-second probe timeout on every call.
The Control UI dashboard polls this endpoint continuously via WebSocket (~every 2s).
Result: event loop is 100% utilized processing 2-second timeouts in a tight loop.
Log evidence:
node.list 2059ms (repeated every ~2s)
liveness warning: eventLoopUtilization=1 cpuCoreRatio=1.546
Suggested fixes
- Temp files: delete .tmp after successful rename; add startup cleanup for orphaned temps
- node.list: return immediately when no nodes configured, or make probe timeout configurable
Environment
- macOS arm64, Mac mini 8GB RAM
- OpenClaw 2026.4.29
- No nodes paired, iMessage + WhatsApp active
Summary
Two related issues that together cause
eventLoopUtilization=1andcpuCoreRatio=1.5+, making the gateway unresponsive (cron tool timeouts, slow responses).Issue 1: Temp files not cleaned up after atomic writes
.tmpfiles accumulate indefinitely after atomic writes:~/.openclaw/devices/paired.json.*.tmp~/.openclaw/cron/jobs-state.json.*.tmp~/.openclaw/update-check.json.*.tmpAfter ~2 weeks of runtime: 150+ paired.json temps, 300+ cron state temps, 67+ update-check temps.
These should be deleted after the atomic rename succeeds. The accumulation causes significant I/O overhead.
Issue 2: node.list probe takes ~2 seconds per call, Control UI polls continuously
With no nodes paired,
node.liststill performs a 2-second probe timeout on every call.The Control UI dashboard polls this endpoint continuously via WebSocket (~every 2s).
Result: event loop is 100% utilized processing 2-second timeouts in a tight loop.
Log evidence:
Suggested fixes
Environment