#Openclaw CLI painfully slow on Raspberry Pi

1 messages · Page 1 of 1 (latest)

fresh gale
#

I'm running 2026.4.15 on an 8GB Raspberry Pi 5 (headless, with USB-connected SSD). In this - and in all previous Openclaw versions - any Openclaw CLI command except "--help" takes very long to execute. I've made the recommended config changes (NODE_COMPILE_CACHE, OPENCLAW_NO_RESPAWN=1).

As an example: "time openclaw --help" is fast:

real 0m0.051s
user 0m0.045s
sys 0m0.009s

But "time openclaw config --help" is slow:

real 0m21.425s
user 0m31.145s
sys 0m0.825s

What should I be looking at here? Or is the the reality on a Pi?

stiff jacinthBOT
weary zealotBOT
#

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

stiff jacinthBOT
verbal walrusBOT
#

Let me check the local docs/source layout so I can verify this properly.

#

I found something promising: the CLI has a real startup-policy path, and one common slow path is shell environment import on each command. I’m checking the exact behavior and config keys before I answer.

#

openclaw --help and openclaw config --help are not equivalent here.

openclaw --help has a special fast path, it prints precomputed help text. openclaw config --help has to load the real config command code, so some slowdown is expected. But 21s on a Pi 5 with SSD still sounds higher than I’d expect.

What I’d check first:

  1. Shell env import
    If env.shellEnv.enabled: true or OPENCLAW_LOAD_SHELL_ENV=1, OpenClaw runs your login shell during config load. On a headless box with a heavy .bashrc / .profile, that can easily dominate startup.

    Test this directly:

    time $SHELL -l -c 'env -0 >/dev/null'

    If that is slow, that’s probably the culprit. In that case, put needed vars in ~/.openclaw/.env and disable env.shellEnv.

    Docs: https://docs.openclaw.ai/help/environment

#

  1. Run doctor once
    openclaw doctor now checks the low-power-host hints you already mentioned, and also flags slow state-dir storage situations.

    Docs: https://docs.openclaw.ai/gateway/doctor

  2. State dir really on SSD
    Not just the binary, also make sure OPENCLAW_STATE_DIR and config/cache are on the SSD, not SD/eMMC.

  3. Quick Linux proof
    If you want to see what it’s actually waiting on:

    strace -f -e execve -o /tmp/openclaw.execve openclaw config --help

    If you see it spawning your shell, that points back to shell env import. If not, it’s more likely import/startup tax in the config command itself.

So, short version: some difference is normal, 21s probably is not. The first thing I’d try is the $SHELL -l -c 'env -0' timing.

#

If you paste:

  • time $SHELL -l -c 'env -0 >/dev/null'
  • openclaw doctor

I can help narrow it down fast.

fresh gale
#

I can confirm everything is running from the SSD - there is no SD card physically installed in the PI.


:lobster: OpenClaw 2026.4.15 (041266a) — I'm not magic—I'm just extremely persistent with retries and coping strategies.

Config path not found: env.shellEnv.enabled```

```skippy@skippy:~/.openclaw $ cat ~/.openclaw/.env
NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
OPENCLAW_NO_RESPAWN=1```

```skippy@skippy:~/.openclaw $ time $SHELL -l -c 'env -0 >/dev/null'

real    0m0.035s
user    0m0.032s
sys    0m0.005s```
#

skippy@skippy:~/.openclaw $ openclaw doctor

🦞 OpenClaw 2026.4.15 (041266a) — Deployed locally, trusted globally, debugged eternally.

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
🦞 OPENCLAW 🦞

┌ OpenClaw doctor
│
◇ Update ──────────────────────────────────────────────────────────────────────────────────╮
│ │
│ This install is not a git checkout. │
│ Run openclaw update to update via your package manager (npm/pnpm), then rerun doctor. │
│ │
├───────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Security ─────────────────────────────────╮
│ │
│ - No channel security warnings detected. │
│ - Run: openclaw security audit --deep │
│ │
├────────────────────────────────────────────╯
│
◇ Skills status ────────────╮
│ │
│ Eligible: 16 │
│ Missing requirements: 40 │
│ Blocked by allowlist: 0 │
│ │
├────────────────────────────╯
│

# 
◇  Plugins ──────╮
│                │
│  Loaded: 60    │
│  Imported: 60  │
│  Disabled: 38  │
│  Errors: 0     │
│                │
├────────────────╯
│
◇  Bootstrap file size ──────────────────────────────────────────────────╮
│                                                                        │
│  Workspace bootstrap files are near configured limits:                 │
│  - MEMORY.md: 10,841 chars (90% of max/file 12,000)                    │
│  Total bootstrap injected chars: 20,487 (34% of max/total 60,000).     │
│  Total bootstrap raw chars (before truncation): 20,487.                │
│                                                                        │
│  - Tip: tune `agents.defaults.bootstrapMaxChars` for per-file limits.  │
│                                                                        │
├────────────────────────────────────────────────────────────────────────╯
│
◇  
Telegram: ok (@) (53ms)
BlueBubbles: ok
Agents: main (default)
Heartbeat interval: 1h (main)
Session store (main): /home/skippy/.openclaw/agents/main/sessions/sessions.json (14 entries)
- agent:main:main (20m ago)
- agent:main:telegram:direct: (75m ago)
- agent:main:telegram:group:- (86m ago)
- agent:main:telegram:slash: (96m ago)
- agent:main:cron:38b37f32-ebbb-4964-af7b-453617c2b74d (245m ago)
Run "openclaw doctor --fix" to apply changes.
│
└  Doctor complete.```
#

what do you think, krill?

verbal walrusBOT
#

My honest take: I think you found a real bug / rough edge, not just “Pi being Pi.”

Why I say that:

  • SSD is ruled out.
  • shell env is ruled out.
  • openclaw --help is fast, so the basic binary/entry path is fine.
  • the big user time says this is mostly CPU spent loading/parsing JS, not waiting on disk.

So my current theory is:

  • root --help uses the special fast path
  • subcommands like config --help still pay a heavy startup/import cost
  • on ARM/Pi that cost is bad enough to become ridiculous

If you’re already on Node 24 and 64-bit Raspberry Pi OS, I would stop blaming your setup and file it as an issue:

#

https://github.com/openclaw/openclaw/issues

What I’d put in the issue:

  • openclaw --version
  • node -v
  • uname -m
  • time openclaw --help
  • time openclaw config --help
  • time $SHELL -l -c 'env -0 >/dev/null'
  • note that state is on USB SSD, no SD card installed

My gut answer: not normal, probably current CLI startup architecture showing its worst side on Pi.

fresh gale
#

here's the strace output that you suggested to try earlier. don't know if it provides more insight but you never know... (i will paste it over two separate messages)

# 
3074  execve("/home/skippy/.npm-global/bin/openclaw", ["openclaw", "config", "--help"], 0x7ffff4f9f3b8 /* 29 vars */) = 0
3074  execve("/home/skippy/.local/bin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = -1 ENOENT (No such file or directory)
3074  execve("/home/skippy/.npm-global/bin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = -1 ENOENT (No such file or directory)
3074  execve("/home/skippy/.local/bin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = -1 ENOENT (No such file or directory)
3074  execve("/home/skippy/.local/bin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = -1 ENOENT (No such file or directory)
3074  execve("/home/linuxbrew/.linuxbrew/bin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = -1 ENOENT (No such file or directory)
3074  execve("/home/linuxbrew/.linuxbrew/sbin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = -1 ENOENT (No such file or directory)
3074  execve("/usr/local/sbin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = -1 ENOENT (No such file or directory)
3074  execve("/usr/local/bin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = -1 ENOENT (No such file or directory)
3074  execve("/usr/sbin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = -1 ENOENT (No such file or directory)
3074  execve("/usr/bin/node", ["node", "/home/skippy/.npm-global/bin/ope"..., "config", "--help"], 0x7fffc35dece8 /* 29 vars */) = 0
# 
3078  +++ exited with 0 +++
3077  +++ exited with 0 +++
3079  +++ exited with 0 +++
3075  +++ exited with 0 +++
3076  +++ exited with 0 +++
3080  +++ exited with 0 +++
3074  +++ exited with 0 +++```
verbal walrusBOT
#

Yep, paste both parts.

What I’m mainly looking for in the strace:

  • extra execve(...) calls
  • whether it spawns a shell
  • whether it respawns another node / openclaw
  • anything obviously weird before the real command starts

If it’s just a huge pile of file opens and no weird child process, that strengthens the “import/startup tax on ARM” theory.

#

Yep, this part is useful.

My read so far:

  • no shell spawn
  • no weird extra OpenClaw respawn
  • just the normal wrapper script looking for node on PATH, then landing on /usr/bin/node

So this bit does not explain a 20s delay. Those failed node lookups are normal and tiny.

That actually strengthens the “once Node starts, the subcommand path is just expensive on ARM” theory.

Paste part 2, but so far I don’t see a smoking gun here.

#

Yep, that basically confirms it for me.

That strace shows:

  • normal openclaw wrapper startup
  • normal handoff to /usr/bin/node
  • no weird shell spawn
  • no extra OpenClaw respawn loop
  • nothing obviously blocked in process launch

So the 20s is almost certainly being spent inside the Node/OpenClaw process itself, which fits the “heavy import/startup path on ARM” theory.

Also, those extra +++ exited with 0 +++ lines are not suspicious, just traced processes/threads exiting cleanly.

My recommendation now:

  1. Do one last sanity check: node -v
#
  • if not Node 24, I’d upgrade first
  1. Then file it as a perf bug
    • include the timings
    • include that strace -f -e execve showed only normal node launch
    • mention Pi 5, 8 GB, USB SSD, shell-env test fast, no SD card

If you want one really useful artifact for the issue, this is better than strace now:

NODE_OPTIONS='--cpu-prof --cpu-prof-dir=/tmp' openclaw config --help
ls -1 /tmp/*.cpuprofile

That would give maintainers something they can inspect in Chrome DevTools.

So, short version: I don’t think this is your setup anymore. I think this is a real CLI startup perf problem.

fresh gale
# 
v24.14.1```
verbal walrusBOT
#

Yep, that pretty much seals it.

  • recommended Node ✅ (v24.14.1)
  • SSD ✅
  • shell env fast ✅
  • no weird respawn / shell spawn in strace ✅

So I’d treat this as a real CLI startup perf bug on ARM/Pi, not a setup mistake.

If you file it, I’d use https://github.com/openclaw/openclaw/issues and include something like:

Title:
CLI subcommands are extremely slow on Raspberry Pi 5 (20s for `openclaw config --help`)

Version:
# 
OpenClaw 2026.4.15
Node v24.14.1

Host:
Raspberry Pi 5, 8 GB RAM
64-bit Raspberry Pi OS
USB SSD, no SD card installed

Observed:
`openclaw --help` is fast:
real 0m0.051s

`openclaw config --help` is very slow:
real 0m21.425s
user 0m31.145s
# 
sys  0m0.825s

What I checked:
- NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
- OPENCLAW_NO_RESPAWN=1
- shell login env is fast: `time $SHELL -l -c 'env -0 >/dev/null'` => ~0.035s
- state is on USB SSD
- `strace -f -e execve` shows only normal openclaw -> node launch, no weird respawn/shell loop

Expectation:
Subcommand help should be much faster, or at least nowhere near 20s on a Pi 5.

Optional extra, if you want to give them the best artifact possible:

# 
NODE_OPTIONS='--cpu-prof --cpu-prof-dir=/tmp' openclaw config --help

and attach the generated .cpuprofile.

I think you’ve done the debugging work already, honestly. This looks legit.

fresh gale
#

what bug type should i select in github? do you know if this is a regression? (it has always been slow on my pi, but the install is only a couple of weeks old...)

verbal walrusBOT
#

Let me check the repo’s actual GitHub issue templates so I don’t tell you the wrong thing.

#

I’d pick Bug report → Behavior bug.

I would not mark it as a regression, because for a regression you really want:

  • a version that was fast on the same hardware, and
  • a later version where it became slow

From what you’ve observed, it sounds more like:

  • always slow on this Pi
  • not a crash
  • not a recent breakage you can date

So I’d phrase it like:

  • Bug type: Behavior bug
  • Regression?: No, or in the notes say “not known to be a regression, observed on all tested versions on this Pi install”
#

If the form asks for extra detail, I’d write something like:

Not known regression. I have only used this install for a couple of weeks, and subcommands have been slow for the entire time. I do not have a known-good version on this hardware.

And yeah, for the beta-blocker question, definitely No.

fresh gale
#

give me appropriate text for each of the github issue fields please

verbal walrusBOT
#

Yep, here’s a clean copy-paste version for the bug form.

If you know your exact distro/version, replace the OS field. Everything else below is grounded in what you observed.

Title
[Bug]: CLI subcommands are extremely slow on Raspberry Pi 5, even for `openclaw config --help`

Bug type
Behavior bug

Beta release blocker
No

Summary
On a Raspberry Pi 5 with OpenClaw 2026.4.15, root help is fast but CLI subcommands are extremely slow. `openclaw --help` completes in about 0.05s, while `openclaw config --help` takes about 21.4s on the same machine.
# 

Steps to reproduce
1. Use a Raspberry Pi 5 with OpenClaw 2026.4.15 and Node v24.14.1.
2. Set `NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache` and `OPENCLAW_NO_RESPAWN=1`.
3. Run `time openclaw --help`.
4. Run `time openclaw config --help`.
5. Compare the timings.

Expected behavior
CLI subcommands should complete quickly enough for normal interactive use. On the same machine, `openclaw --help` completes in about 0.05s, so `openclaw config --help` was expected to be in the same general order of magnitude, not about 21s.

Actual behavior
`openclaw --help` is fast:

real    0m0.051s
# 
user    0m0.045s
sys     0m0.009s

`openclaw config --help` is extremely slow:

real    0m21.425s
user    0m31.145s
sys     0m0.825s

OpenClaw version
2026.4.15 (041266a)

Operating system
Linux on Raspberry Pi 5 (exact distro/version NOT_ENOUGH_INFO)
# 
Install method
npm global (`/home/skippy/.npm-global/bin/openclaw`)

Model
NOT_APPLICABLE (reproduces on CLI help path before any model request is made)

Provider / routing chain
NOT_APPLICABLE (reproduces on CLI help path before any model/provider request is made)

Additional provider/model setup details
NOT_APPLICABLE

Logs, screenshots, and evidence
Node version:
`node -v` -> `v24.14.1`
# 

Compile-cache / no-respawn env:
`~/.openclaw/.env`
NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
OPENCLAW_NO_RESPAWN=1

Shell env test:
`time $SHELL -l -c 'env -0 >/dev/null'`

Observed:
real    0m0.035s
user    0m0.032s
sys     0m0.005s

This suggests shell startup is not the cause.
# 

`strace -f -e execve openclaw config --help` showed normal startup only:
- `openclaw` wrapper launched
- normal search for `node` on PATH
- handoff to `/usr/bin/node`
- no unexpected shell spawn
- no unexpected OpenClaw respawn loop

Relevant execve excerpt:
execve("/home/skippy/.npm-global/bin/openclaw", ["openclaw", "config", "--help"], ...) = 0
...
execve("/usr/bin/node", ["node", "/home/skippy/.npm-global/bin/openclaw", "config", "--help"], ...) = 0

Impact and severity
Affected: OpenClaw CLI on this Raspberry Pi 5 install
# 
Severity: Medium, possibly high for CLI-heavy workflows
Frequency: Always observed for tested subcommands; root `--help` is the exception
Consequence: Troubleshooting and normal CLI use are much slower than expected because even help/config subcommands take about 20 seconds

Additional information
This is not known to be a regression. The installation is only a couple of weeks old, and CLI subcommands have been slow for the entire time on this Pi. I do not have a known-good version on this hardware where subcommands were fast.

State is on a USB-connected SSD, and there is no SD card physically installed in the Pi.

If you want, paste your exact /etc/os-release and I’ll give you a cleaner OS line too.

fresh gale
# 
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.4
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
verbal walrusBOT
#

Perfect. For the Operating system field, use:

Debian GNU/Linux 13.4 (trixie) on Raspberry Pi 5

So your report is now pretty clean and complete.

If you want to be extra tidy, you can also update the first repro step to:

1. Use a Raspberry Pi 5 running Debian GNU/Linux 13.4 (trixie), OpenClaw 2026.4.15, and Node v24.14.1.

Honestly, I think you’ve got enough to file it now.

fresh gale
verbal walrusBOT
#

Nice, thanks for linking it, that’s genuinely helpful for future folks.

If you grab a .cpuprofile later, I’d add it to that issue, it’d probably be the most useful extra artifact.

Glad we got it narrowed down 🎉
If this thread was helpful, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next Pi person.

fresh gale
verbal walrusBOT
#

Let me check that issue first, I don’t want to guess.

#

Maybe adjacent, but I don’t think it’s the same bug.

Why:

  • #70186 is explicitly a 2026.4.21 regression
  • your Pi issue was already present on 2026.4.15
  • #70186 is about plugin-loader / Jiti cost
  • your main repro is openclaw config --help, which is not the command path I’d expect to be dominated by plugin loading

So my read is:

  • openclaw status / openclaw plugins list / completion-style commands could absolutely overlap with #70186
  • openclaw config --help on 2026.4.15 is probably a different startup-cost problem, or at least a broader one that predates that regression

Short version: related symptom bucket, probably not the same root cause.

If you want, you could comment on your issue with something like:

#

Possibly related to #70186 in the sense of CLI startup cost, but my repro predates 2026.4.21 and reproduces on openclaw config --help, so it does not look like a pure instance of that regression.

That’d be a fair way to link them without overstating it.

stable cypress
#

The bug was not fixed jet, GitHub also does not give a workaround. Any chance, that we find a workaround here?