Summary
When running claudecodeui/cloudcli in the background, the node process keeps using noticeable CPU (~10–20%) even when idle. From investigation, the main cause appears to be repeated filesystem scanning (stat/lstat) of Cursor chat history databases under ~/.cursor/chats/**/store.db* (including -wal/-shm/-journal).
Environment
- macOS: 15.3.1 (Apple Silicon / ARM64)
- cloudcli: v1.22.0
- Node: /opt/homebrew/Cellar/node/25.6.1_1/bin/node
- cursorcli: installed (Cursor chat history exists under
~/.cursor/chats)
What I’m seeing
cloudcli runs as: node /opt/homebrew/bin/cloudcli
- CPU stays around ~10–20% for long periods while “idle”
fs_usage shows continuous stat64/lstat64 calls against Cursor chat DB files, e.g.
~/.cursor/chats/<hash>/<session>/store.db
~/.cursor/chats/<hash>/<session>/store.db-wal
~/.cursor/chats/<hash>/<session>/store.db-shm
~/.cursor/chats/<hash>/<session>/store.db-journal
Example (sudo fs_usage -w -f filesystem <pid> | egrep "stat64|lstat64|getattrlist"):
(paste a few lines here)
Expected behavior
When idle, cloudcli should be near-zero CPU and should not continuously scan Cursor chat history DB files.
Notes / suspected cause
It looks like Cursor sessions/chat history discovery is being polled too frequently (or lacking caching/throttling), causing repeated scans of ~/.cursor/chats. Adding caching/throttling, or only fetching Cursor sessions on-demand (e.g., for the selected project/provider), might prevent this continuous scanning.
Summary
When running claudecodeui/cloudcli in the background, the node process keeps using noticeable CPU (~10–20%) even when idle. From investigation, the main cause appears to be repeated filesystem scanning (stat/lstat) of Cursor chat history databases under
~/.cursor/chats/**/store.db*(including-wal/-shm/-journal).Environment
~/.cursor/chats)What I’m seeing
cloudcliruns as:node /opt/homebrew/bin/cloudclifs_usageshows continuousstat64/lstat64calls against Cursor chat DB files, e.g.~/.cursor/chats/<hash>/<session>/store.db~/.cursor/chats/<hash>/<session>/store.db-wal~/.cursor/chats/<hash>/<session>/store.db-shm~/.cursor/chats/<hash>/<session>/store.db-journalExample (
sudo fs_usage -w -f filesystem <pid> | egrep "stat64|lstat64|getattrlist"):(paste a few lines here)
Expected behavior
When idle, cloudcli should be near-zero CPU and should not continuously scan Cursor chat history DB files.
Notes / suspected cause
It looks like Cursor sessions/chat history discovery is being polled too frequently (or lacking caching/throttling), causing repeated scans of
~/.cursor/chats. Adding caching/throttling, or only fetching Cursor sessions on-demand (e.g., for the selected project/provider), might prevent this continuous scanning.