openclaw - 💡(How to fix) Fix [Bug]: High idle CPU on macOS gateway, possibly related to chokidar awaitWriteFinish polling

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On macOS, the OpenClaw gateway process consistently uses 60–93% CPU at idle, even when there are no active cron jobs, sub-agents, tool calls, or active user sessions.

Steps to reproduce

1. Run OpenClaw 2026.5.22 on macOS with the gateway launched via LaunchAgent.
2. Keep the gateway idle, with no active cron jobs, sub-agents, tool calls, or active user sessions.
3. Observe the gateway Node.js process CPU usage with ps or Activity Monitor.
4. Sample the gateway process using macOS sample.

Expected behavior

When idle, the OpenClaw gateway should drop to a low CPU usage level and should not continuously consume high CPU when no cron jobs, sub-agents, tool calls, or active user requests are running.

Actual behavior

The gateway process remains around 60–93% CPU while idle. Restarting the gateway temporarily lowers CPU usage to around 50%, but it climbs again over time. Telegram remains usable, but typing can be delayed by a few seconds.

OpenClaw version

2026.5.22 (a374c3a)

Operating system

macOS 26.4.1, Intel MacBook Pro

Install method

npm global, launched via macOS LaunchAgent

Model

deepseek/deepseek-v4-pro

Provider / routing chain

OpenClaw gateway using the configured model provider. The high CPU occurs while idle and does not appear to be caused by remote model inference.

Additional provider/model setup details

The model provider does not appear to be the cause because the high CPU occurs when no active model request, tool call, cron job, or sub-agent is running.

Logs, screenshots, and evidence

Environment

| Item             | Detail                                            |
| ---------------- | ------------------------------------------------- |
| OpenClaw version | 2026.5.22 (a374c3a)                               |
| Node.js          | v22.22.2 (Homebrew)                               |
| macOS            | macOS 26.4.1, Intel MacBook Pro                   |
| Hardware         | Intel Core i5-1038NG7 @ 2.00GHz (4-core)          |
| Gateway install  | npm global (/usr/local/lib/node_modules/openclaw) |
| Gateway launch   | LaunchAgent (ai.openclaw.gateway.plist)           |
| Default model    | deepseek/deepseek-v4-pro                          |

Diagnosis Process

1. Load average check: 3.5–4.0 on a 4-core machine, mostly from a single gateway Node.js process.

2. Process inspection:
- Single gateway process, no duplicates.
- Established TCP connections to Telegram API.
- sqlite WAL being written normally.
- Session JSONL file open with lock, normal for active session.

3. Log investigation:
- Historical: 20,196 gmail-watcher stopped events logged between 2026-05-20 and 2026-05-24, roughly every 16 seconds. This loop stopped after a gateway restart and has not recurred.
- Current: No repeated errors, timeouts, connector failures, or polling warnings in logs.

4. CPU sampling:
- 100% of sampled time in uv_run.
- 12.7% of all samples in filesystem operations: lstat$INODE64, stat$INODE64, __opendir2, open$NOCANCEL.
- About 73 lstat calls in 5 seconds, around 14.6 stat calls per second.
- Remaining time dominated by uv__io_poll, uv__run_timers, and V8 GC/compilation.

5. Source code observation:
Two chokidar.watch() instances are created by the gateway:
- Config reload watcher: watches openclaw.json with awaitWriteFinish pollInterval around 50ms.
- Skills file watcher: watches workspace and plugin skills directories with depth=2 and awaitWriteFinish pollInterval around 100ms.

Impact and severity

Affected system: OpenClaw gateway on macOS.

Severity: Medium. The system remains usable, but the gateway consumes high idle CPU, increasing power usage, heat, and background load. Telegram responses are still delivered, but typing can be delayed by a few seconds.

Frequency: Observed consistently during the diagnostic period while the gateway was idle.

Consequence: Higher CPU usage, possible battery drain / fan noise / heat, and reduced responsiveness on an Intel Mac.

Additional information

Suspected Cause

The two chokidar watchers both appear to use awaitWriteFinish, which can force chokidar to poll watched files/directories with stat() at the configured pollInterval even when native FSEvents are available.

• Skills watcher: polls skill directories every 100ms.
• Config watcher: polls openclaw.json every 50ms.

Could maintainers confirm whether awaitWriteFinish is required for these watchers on macOS, and whether a config option could be added to disable it or make it opt-in?

Possible improvements:

• Make awaitWriteFinish opt-in.
• Use native FSEvents without stat polling where possible.
• Provide a documented config option to disable skills/config file watchers in production.
• Provide a documented way to disable hot reload watchers when not needed.