#Very high CPU usage when running openclaw CLI

1 messages · Page 1 of 1 (latest)

vagrant anchor
#

I observe very high CPU usage recently especially when i run the openclaw CLI commands (even just the help page)

frosty sirenBOT
radiant bronzeBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

frosty sirenBOT
umbral plinthBOT
#

I’m checking the docs/source for any known high-CPU regressions or common causes, then I’ll give you the shortest useful triage path.

#

That sounds abnormal.

First, can you paste:

openclaw --version

Then please try these two exact checks:

time openclaw --help >/dev/null
OPENCLAW_RUNNER_LOG=1 openclaw --help >/dev/null

A couple reasons I’m asking for those specifically:

#
  • current builds have a lightweight root --help fast path, so if that still spikes CPU, something in startup is off
  • if you’re running from a git/source checkout, the wrapper can rebuild dist on any CLI invocation when it thinks the tree is stale, which would explain high CPU even for help

If the second command prints something like dist is stale with reasons such as dirty_watched_tree, git_head_changed, config_newer, or source_mtime_newer, we’ve probably found it.

Also tell me whether this is:

  • a normal installed package, or
  • a repo/source checkout

Docs:

Paste those outputs and I’ll narrow it down with you.

vagrant anchor
#

ok i was wrong --help is fast. running things like "gateway status" is causing high cpu usage.

OpenClaw 2026.4.15 (041266a)

umbral plinthBOT
#

Got it, that’s a much better signal. I’m checking what gateway status actually does in this build so I can point you at the likely hot path instead of guessing.

#

Nice, that narrows it a lot.

I checked the current code path, and openclaw gateway status is not a cheap command. On your build it does roughly:

  • service/runtime inspection
  • config audit
  • port-owner inspection via lsof or ss
  • extra ps lookups for the listener PID(s)
  • a live gateway probe
  • and, when probing is on, an extra restart-health check that inspects the port again

So --help being fast but gateway status being hot actually makes sense.

Can you compare these two:

# 
time openclaw gateway status --no-probe
time openclaw gateway status

Interpretation:

  • if --no-probe is much cheaper, the expensive part is the live probe / restart-health path
  • if both are hot, the likely culprit is the local port inspection path (lsof / ss / ps)

If both are hot, also try:

time ss -H -ltnp 'sport = :18789'

and if ss is missing:

vagrant anchor
#

--no-probe behaves exactly the same. extremely high CPU usage


real    0m0.039s
user    0m0.000s
sys    0m0.009s
openclaw@openclaw:~$ time openclaw gateway status --no-probe
Port 18789 is already in use.
- pid 813 openclaw: openclaw-gateway (127.0.0.1:18789)
- Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.

real    0m14.394s
user    0m21.052s
sys    0m0.983s```
umbral plinthBOT
#

That output is weird, and actually really helpful. I’m searching the exact message in source, because gateway status --no-probe should not be trying to bind the port at all.

#

Ah, that’s the smoking gun.

I checked the exact error text in source, and that output is from the gateway start/run path, not the gateway status handler.

So openclaw gateway status --no-probe is almost certainly not hitting the right command surface on your machine. That also explains the huge CPU use.

Please paste these:

which openclaw
readlink -f "$(command -v openclaw)"
openclaw gateway --help

What I expect:

  • openclaw gateway --help should list status, start, stop, restart, etc.
  • if it does not, you likely have a stale/mismatched wrapper or dist build on PATH