Openclaw slow | Friends of the Crustacean 🦞🤝 | Page 1

cold frost Apr 8, 2026, 2:14 PM

#

Since version 2026.4.5, Openclaw has become significantly slower. Even a simple CLI call takes a long time
(the machine has 16GB, SSD with ~1166 MB/s)

time oc skills info printer

🦞 OpenClaw 2026.4.8 (9ece252) — We ship features faster than Apple ships calculator updates.

🖨️ printer ✓ Ready

Manage and interact with network printers using Python and pycups (CUPS). Use this skill whenever the user wants to list available printers on the network, print a file or a web page/URL, or configure printing options (simplex/duplex). If only one printer is available it is selected automatically.

Details:
  Source: openclaw-extra
  Path: ~/apps/skills/printer/SKILL.md

Tip: use `openclaw skills search`, `openclaw skills install`, and `openclaw skills update` for ClawHub-backed skills.

real    0m26.096s
user    0m24.993s
sys     0m3.106s

What could be the cause?

frozen spokeBOT Apr 8, 2026, 2:14 PM

#

void patioBOT Apr 8, 2026, 2:14 PM

#

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

frozen spokeBOT Apr 8, 2026, 2:14 PM

#

mild hawk Apr 13, 2026, 3:41 AM

#

nudge

toxic swiftBOT Apr 13, 2026, 3:47 AM

#

This looks like a CLI startup regression, not a RAM/SSD problem.

I reproduced it locally:

openclaw --version: ~0.3s
openclaw help: ~17s
openclaw status: ~11s
openclaw skills info/list: ~16s

So the slow part is starting the CLI process, before the actual command does much.

Most likely cause:

startup is doing a ton of filesystem scanning
strace showed huge churn under:
- .../openclaw/dist/extensions
- .../openclaw/node_modules
- ~/.openclaw/plugins

#

The suspicious code path is roughly:

run-main.ts
buildProgram()
createProgramContext()
resolveCliChannelOptions()
channels/ids.ts
listChannelCatalogEntries()
discoverOpenClawPlugins()

So even a simple CLI command can end up eagerly scanning bundled/custom plugins and channel manifests.

In short, I’d bet the cause is:

plugin/channel discovery happening on every CLI invocation
too much eager import/scanning during startup
extra slowdown if you have more stuff in ~/.openclaw/plugins

Quick confirmation on your box:

#

time openclaw --version
time openclaw help
time openclaw status
strace -f -c openclaw help

If --version is fast but help/status are slow, that strongly confirms startup regression.

This smells like a real bug introduced in the newer CLI startup path. If you want, I can help turn this into a clean GitHub issue with the likely culprit and repro steps.

mild hawk Apr 13, 2026, 3:53 AM

#

node@7a440ac70693:/app$ time openclaw --version
OpenClaw 2026.3.28

real    0m0.394s
user    0m0.163s
sys     0m0.029s
node@7a440ac70693:/app$ time openclaw help

🦞 OpenClaw 2026.3.28 (unknown) — Your AI assistant, now without the $3,499 headset.

Usage: openclaw [options] [command]

Options:
  --container <name>   Run the CLI inside a running Podman/Docker container named <name> (default: env OPENCLAW_CONTAINER)
  --dev                Dev profile: isolate state under ~/.openclaw-dev, default gateway port 19001, and shift derived ports (browser/canvas)

<deleted irrelevant details>

real    0m50.451s
user    0m49.903s
sys     0m2.408s
node@7a440ac70693:/app$ strace -f -c openclaw help
bash: strace: command not found
node@7a440ac70693:/app$

toxic swiftBOT Apr 13, 2026, 3:53 AM

#

Yep, this makes the diagnosis a lot clearer.

openclaw --version being fast, but openclaw help taking 50s, means this is not gateway/model/network latency. It’s almost certainly CLI startup work.

What it points to:

OpenClaw is doing expensive startup scanning before the real command runs
the likely hot path is plugin/channel discovery
in source, that path ends up walking bundled extensions/plugin manifests just to build CLI context
in a container, that can get even worse because lots of tiny file lookups on overlay filesystems are painful

So the likely cause is:

too much eager filesystem scanning at startup
plugin/channel catalog discovery running on every CLI invocation
container filesystem overhead amplifying it

Also, your new result is important:

#

this is visible on 2026.3.28 too
so 2026.4.5 may have worsened it for you, but it probably was already present earlier

A very good extra check is:

time openclaw --help
time openclaw help

If --help is much faster than help, that strongly confirms it’s the normal CLI boot path, not the help text itself.

At this point I’d call it a real startup regression / architecture issue, not a machine-spec problem.

If you file a GitHub issue, I’d include:

exact version
“running inside container”

#

time openclaw --version
time openclaw --help
time openclaw help
time openclaw status

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

If you want, I can help write the issue text cleanly.

mild hawk Apr 13, 2026, 3:56 AM

#

node@7a440ac70693:/app$ time openclaw --help

🦞 OpenClaw 2026.3.28 (unknown) — Welcome to the command line: where dreams compile and confidence segfaults.

Usage: openclaw [options] [command]

<irralavent details deleted>

  openclaw gateway ...
    Gateway control via WebSocket.
  openclaw agent --to +15555550123 --message "Run summary" --deliver
    Talk directly to the agent using the Gateway; optionally send the WhatsApp reply.
  openclaw message send --channel telegram --target @mychat --message "Hi"
    Send via your Telegram bot.

Docs: https://docs.openclaw.ai/cli


real    0m0.148s
user    0m0.043s
sys     0m0.010s
node@7a440ac70693:/app$

I don't mind minimizing plugin usage, and minimizing "channel discovery" (whatever that is). I am new to OpenClaw, I shouldn't have a lot of plugins anyway, maybe i haven't taken the necessary steps to disable them

toxic swiftBOT Apr 13, 2026, 3:57 AM

#

No, I don’t think you missed a setup step.

What your timings say is:

openclaw --help is fast because it uses a special fast path
openclaw help is slow because it goes through the normal CLI startup path

So this is much more likely an internal startup/design issue than “you forgot to disable plugins”.

And “channel discovery” here does not mean you manually enabled a bunch of channels. It’s OpenClaw internally enumerating bundled chat/plugin surfaces so it can build the CLI context. A fresh install can still pay that cost.

So I’d frame it like this:

your custom plugins are probably not the main problem
disabling a few user plugins might help a little
but it likely won’t fix the big slowdown, because the expensive part seems to be bundled startup scanning

#

If you want to inspect what is actually enabled, these are the right commands:

openclaw plugins list --enabled
openclaw plugins disable <id>

Docs:

But honestly, with the numbers you posted, I’d expect the real fix to be in OpenClaw itself, for example making that startup discovery lazy or precomputed.

So short version: this is probably not user misconfiguration. It looks like a CLI startup regression/architectural issue.

mild hawk Apr 13, 2026, 3:58 AM

#

so... nothing can be done in the meantime?

toxic swiftBOT Apr 13, 2026, 3:58 AM

#

A few things can help, but yeah, none of them look like a real fix.

Best interim mitigations:

Use --help, not help
- openclaw --help hits the fast path
- openclaw help goes through the slow full startup path
If you’re in Docker/Podman, try running on the host
- this kind of “many tiny file lookups” often gets worse on container/overlay filesystems
Keep custom plugins/extra skill dirs minimal
- especially anything under ~/.openclaw/plugins
- and any extra plugin/skill load paths you added
- this probably only helps a bit, but it’s the main user-side lever
Prefer long-lived workflows over lots of one-shot CLI calls

#

keep the gateway running
- use the dashboard / persistent agent session when possible
- the pain is mostly paying startup cost over and over

So, “nothing can be done” is a bit too pessimistic, but “there’s no clean user-side fix yet” is probably accurate.

If you want, I can help you narrow it down to the most useful temporary test:

host vs container
empty state dir vs current state dir
bundled-only vs custom plugins enabled

That would tell us whether there’s a practical workaround on your machine.

mild hawk Apr 13, 2026, 4:01 AM

#

I don't use 99% of this list

node@7a440ac70693:/app$ openclaw plugins list --enabled

🦞 OpenClaw 2026.3.28 (unknown) — Less clicking, more shipping, fewer "where did that file go" moments.

Plugins (44/44 loaded)
Source roots:
  stock: /app/extensions

┌─────────────────────────────────────────────────┬────────────────────────────────────────┬──────────┬──────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────┬───────────┐
│ Name                                            │ ID                                     │ Format   │ Status   │ Source                                                                                                      │ Version   │
├─────────────────────────────────────────────────┼────────────────────────────────────────┼──────────┼──────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────┼───────────┤
│ Amazon Bedrock Provider                         │ amazon-bedrock                         │ openclaw │ loaded   │ stock:amazon-bedrock/index.ts                                                                               │ 2026.3.28 │
│                                                 │                                        │          │          │ Bundled 

<rest of list deleted for the sake of discussion>

toxic swiftBOT Apr 13, 2026, 4:02 AM

#

Yeah, that list is basically the smoking gun.

If a fresh-ish install is loading 44 bundled plugins, and you only use a handful, then yes, that can absolutely contribute to the startup cost.

So there is one reasonable meantime workaround:

Try a restrictive plugin allowlist

Set plugins.allow so OpenClaw only loads the plugins you actually need.

Docs:

Important caveats:

you’ll need to include the model provider(s) you use
plus any channel plugin(s) you use
maybe a couple utility ones, depending on your setup

#

config changes need a gateway restart

This is probably better than manually disabling 40+ plugins one by one.

I would treat it as a workaround, not a real fix:

if startup gets much faster, that confirms plugin loading is a big part of the problem
if it barely changes, then the deeper issue is the bundled discovery/startup path itself

So, short answer: yes, in the meantime, limiting loaded plugins is probably the most promising user-side mitigation.

mild hawk Apr 13, 2026, 4:02 AM

#

what is a "channel plugin"? Discord?

toxic swiftBOT Apr 13, 2026, 4:02 AM

#

Yep, exactly.

A channel plugin is the integration for a messaging surface, for example:

Discord
Telegram
WhatsApp
Slack
Signal
etc.

So:

if you use OpenClaw through Discord, then yes, Discord is one of the channel plugins you’d need
if you’re only using the CLI locally, you may not need any channel plugins at all

Separate from that are provider/model plugins, like the ones for whichever AI provider you actually use.

#

So the rough idea would be:

keep the provider plugin(s) you need
keep the channel plugin(s) you need, if any
drop the rest from the allowlist

That’s why I called it a workaround, it depends a bit on how you use OpenClaw.

mild hawk Apr 13, 2026, 4:04 AM

#

show me the openclaw.json to allow only a few plugins please

toxic swiftBOT Apr 13, 2026, 4:05 AM

#

Sure, I’d start with something like this in ~/.openclaw/openclaw.json:

{
  plugins: {
    enabled: true,

    // Only load the plugins you actually need.
    // Use the exact IDs from: openclaw plugins list --enabled
    allow: [
      "<your-provider-plugin-id>",

      // Uncomment only if you actually use a chat surface:
      // "discord",
      // "telegram",
      // "slack",

#


      // Uncomment only if you actually need them:
      // "<browser-plugin-id>",
      // "<memory-plugin-id>",
      // "<acp-plugin-id>",
    ],

    deny: [],
    entries: {
      "<your-provider-plugin-id>": { enabled: true },

      // Optional, only if you use them:
      // discord: { enabled: true },
      // telegram: { enabled: true },
    },

#

  },
}

If you want a more concrete example, for CLI-only usage it would look roughly like:

{
  plugins: {
    enabled: true,
    allow: [
      "<your-provider-plugin-id>"
    ],
    deny: [],
    entries: {

#

      "<your-provider-plugin-id>": { enabled: true }
    },
  },
}

A few important notes:

use the exact plugin IDs from openclaw plugins list --enabled
if you make the allowlist too small, some commands/features will disappear
after changing this, restart the gateway

Docs:

#

If you paste the first 10 to 15 plugin IDs from your plugins list --enabled, I can help you trim that to a realistic minimal allowlist.

mild hawk Apr 13, 2026, 4:07 AM

#

oh mine is already like this:

  "plugins": {
    "entries": {
      "google": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": "<redacted>"
          }
        }
      },
      "synology-chat": {
        "enabled": true,
        "config": {}
      },
      "whatsapp": {
        "enabled": true,
        "config": {}
      },
      "browser": {
        "enabled": true,
        "config": {}
      }
    }
  },

Should I actually go ahead and use the cli to disable the unnecessary ones one by one then?

toxic swiftBOT Apr 13, 2026, 4:07 AM

#

Ah, yep, that explains it.

plugins.entries is not the same as plugins.allow.

What you have now says:

“these specific plugins are enabled/configured”

It does not say:

“only load these plugins”

So no, I would not start by disabling 40 things one by one.

I’d do this instead:

"plugins": {

#

  "allow": ["google", "synology-chat", "whatsapp", "browser"],
  "entries": {
    "google": {
      "enabled": true,
      "config": {
        "webSearch": {
          "apiKey": "<redacted>"
        }
      }
    },
    "synology-chat": {
      "enabled": true,
      "config": {}
    },
    "whatsapp": {

#

      "enabled": true,
      "config": {}
    },
    "browser": {
      "enabled": true,
      "config": {}
    }
  }
}

Then:

restart the gateway
retest:

#

   time openclaw help
   time openclaw skills info printer

Also, if you don’t actually use one of those, leave it out of allow.

For example:

no Synology Chat → remove synology-chat
no WhatsApp → remove whatsapp
no browser tool → remove browser

So the short answer is:

don’t disable one by one first
add plugins.allow
make the loaded set explicit

#

then test

Docs: https://docs.openclaw.ai/tools/plugin

mild hawk Apr 13, 2026, 4:10 AM

#

ok... same goes for skills? I now have this:

  "skills": {
    "entries": {
      "wacli": {
        "enabled": true
      }
    }
  },

toxic swiftBOT Apr 13, 2026, 4:10 AM

#

Similar idea, but not exactly.

For skills:

skills.entries.<name> = per-skill overrides, for example enable/disable or API key/env
it does not mean “only load this skill”

If you want to restrict bundled skills, the relevant key is:

skills.allowBundled

Example:

"skills": {
  "allowBundled": ["wacli"],

#

  "entries": {
    "wacli": {
      "enabled": true
    }
  }
}

Important nuance:

allowBundled only affects bundled skills
it does not block managed/workspace skills or skills.load.extraDirs

Also, I’d still focus on plugins first, because your openclaw help slowdown points more strongly at startup/plugin loading than at skills.

So:

add plugins.allow first

#

retest
then, if needed, tighten skills.allowBundled

Docs: https://docs.openclaw.ai/gateway/configuration-reference

mild hawk Apr 13, 2026, 4:51 AM

#

added the "allow" in "plugins". Still slow. and when i do this, there is still 39:

node@7a440ac70693:/app$ time openclaw plugins list --enabled

🦞 OpenClaw 2026.3.28 (unknown) — I'm the middleware between your ambition and your attention span.

Plugins (39/39 loaded)
Source roots:
  stock: /app/extensions

┌─────────────────────────────────────────────────┬────────────────────────────────────────┬──────────┬──────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────┬───────────┐
│ Name                                            │ ID                                     │ Format   │ Status   │ Source                                                                                                      │ Version   │
├─────────────────────────────────────────────────┼────────────────────────────────────────┼──────────┼──────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────┼───────────┤
│ Amazon Bedrock Provider                         │ amazon-bedrock                         │ openclaw │ loaded   │ stock:amazon-bedrock/index.ts                                                                               │ 2026.3.28 │
│                                                 │                                        │          │          │ Bundled Amazon Bedrock provider policy plugin                                                               │           │
<omitted rest of list>

toxic swiftBOT Apr 13, 2026, 4:53 AM

#

That’s a really useful datapoint, and honestly it changes my read a bit.

If adding plugins.allow didn’t make it faster, then the main cost is probably not just “too many enabled plugins”.

More likely:

OpenClaw is still doing expensive plugin discovery / metadata scanning over /app/extensions
and that work happens before the allowlist meaningfully helps

Also, openclaw plugins list --enabled is kind of a worst-case command here, because it has to inspect plugin state, so I wouldn’t use that one as the success metric.

So the updated conclusion is:

good test, but allowlist is not enough
the slow part seems to be core startup/discovery
this is probably not fixable cleanly with config alone

I’m glad you tested it, because that makes this look much more like a real upstream bug than a config mistake.

#

At this point I’d summarize the bug as:

openclaw --help is fast
openclaw help / skills info are very slow
restrictive plugins.allow does not materially help
bundled extension scanning still appears heavy in container installs

That’s a solid GitHub issue. If you want, I can write the exact issue text for you so you can paste it into https://github.com/openclaw/openclaw/issues.

mild hawk Apr 13, 2026, 4:56 AM

#

it is a LITTLE faster now, before the time openclaw help command was 50.451s like i showed above, now it is 38.657s

toxic swiftBOT Apr 13, 2026, 4:56 AM

#

That’s actually pretty informative.

Going from 50.4s → 38.7s means the allowlist did help some, so plugin load/activation is part of it.

But 38 seconds is still wildly too slow, so the bigger problem is still elsewhere, probably startup discovery / metadata scanning.

So the picture now looks like:

plugin allowlist helps a bit
it does not solve the main slowdown
root cause is still likely core CLI startup work

That’s a stronger bug report, honestly. You now have evidence that:

--help fast path is fine
normal CLI startup is slow
trimming plugins reduces the cost a little

#

most of the slowdown remains

If you want, I can turn all of this into a tight GitHub issue body you can paste directly.

mild hawk Apr 13, 2026, 4:57 AM

#

github issue is one thing, but can i do any workaround in the meantime? so you think disabling one by one won't help?

toxic swiftBOT Apr 13, 2026, 4:57 AM

#

I think one-by-one disabling might help a bit more, but I don’t think it’s likely to turn 39s into something normal.

You already did the best signal test:

restrictive allowlist took you from ~50s to ~39s

That suggests:

plugin trimming can shave some time
but the majority of the cost is still elsewhere

So my honest take is:

Worth doing

keep the restrictive plugins.allow
if possible, also trim bundled skills with skills.allowBundled
use openclaw --help instead of openclaw help
if you can, run outside the container, because this kind of startup I/O often gets worse there
prefer long-lived workflows over repeated one-shot CLI calls

#

Probably not worth spending a ton of time on

disabling 30 plugins one by one and hoping it fixes the whole thing

If you really want to squeeze a few more seconds out, I’d only try disabling the most obvious unused stuff first:

unused chat channels
browser, if you don’t use the browser tool
anything extra beyond your actual provider + actual channel

But I’d expect incremental improvement, not a real fix.

So, short answer:

yes, it might help a little
no, I would not expect it to solve the problem

If you want, I can help you pick the highest-probability 5 to remove first instead of doing it blindly.

mild hawk Apr 13, 2026, 4:57 AM

#

please

toxic swiftBOT Apr 13, 2026, 4:58 AM

#

Yep. Based on what you’ve shown, I’d trim in this order:

synology-chat, if you don’t actively use it
whatsapp, if you don’t actively use it
browser, if you don’t use the browser tool / openclaw browser
all other chat/channel plugins you don’t use at all
- Discord, Telegram, Slack, Signal, etc.
voice / memory / extra capability plugins you don’t use
- speech, transcription, realtime voice, memory/wiki/dreaming-type stuff

What I would keep first

google, since you explicitly configured it

Smallest practical experiment

If your actual usage is basically just local CLI + Google-backed stuff, I’d try an allowlist that is as small as possible first, for example:

#

"plugins": {
  "allow": ["google"]
}

Then add back only what you really need:

add browser only if you actually use browser features
add whatsapp only if you actually use WhatsApp
add synology-chat only if you actually use Synology Chat

So the shortest version is:

first cut: keep only google
next add-back candidates: browser, whatsapp, synology-chat, only if truly needed

If you want, paste 10 to 20 of the plugin IDs from your enabled list and I’ll mark them as:

#

keep
probably remove
maybe keep if you use X

mild hawk Apr 13, 2026, 4:58 AM

#

how to manually disable one by one with CLI?

toxic swiftBOT Apr 13, 2026, 4:59 AM

#

Yep, for plugins:

openclaw plugins disable <plugin-id>

Example:

openclaw plugins disable whatsapp
openclaw plugins disable synology-chat
openclaw plugins disable browser

To turn one back on:

#

openclaw plugins enable <plugin-id>

Example:

openclaw plugins enable browser

Useful checks:

openclaw plugins list --enabled
openclaw plugins inspect <plugin-id>

#

Docs: https://docs.openclaw.ai/cli/plugins

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. This helps Answer Overflow index the solution for future users.

mild hawk Apr 13, 2026, 5:00 AM

#

so these disablings are permenant right? it won't come back when i restart gateway?

toxic swiftBOT Apr 13, 2026, 5:00 AM

#

Normally, yes.

openclaw plugins disable <id> writes it into your config as:

plugins.entries.<id>.enabled = false

So it should stay disabled across gateway restarts until you:

run openclaw plugins enable <id>
edit openclaw.json
or some other config change re-enables it

So for normal use, treat it as persistent, not just for the current session.

mild hawk Apr 13, 2026, 5:31 AM

#

disabling in openclaw.json didn't obviously help. so the "allow" line did help, but not disabling

toxic swiftBOT Apr 13, 2026, 5:31 AM

#

Yep, that actually makes sense.

It suggests:

plugins.allow helps because it trims the eligible plugin set earlier
plugins.entries.<id>.enabled = false happens later, after OpenClaw has already done a lot of discovery/inspection work

So your result is consistent with:

the expensive part is mostly discovery/startup scanning
not just “activating enabled plugins”

Which is annoying, but it’s a pretty strong clue.

So I’d treat this as the current best summary:

plugins.allow gives a small real improvement

#

individual disables do little or nothing
the main cost is still in core startup/plugin discovery

That’s a much cleaner diagnosis than we had at the start.

mild hawk Apr 13, 2026, 5:31 AM

#

any other help you can think of???

toxic swiftBOT Apr 13, 2026, 5:32 AM

#

A couple more things, but we’re getting close to the limit of what config can do.

1. Try a totally fresh state dir

This is a good high-signal test:

mkdir -p /tmp/oc-empty
OPENCLAW_STATE_DIR=/tmp/oc-empty time openclaw --help
OPENCLAW_STATE_DIR=/tmp/oc-empty time openclaw help

Why:

if help is still very slow, that points even more strongly at bundled startup scanning
if it gets much faster, then your normal state/config is contributing more than we thought

2. If possible, test outside the container

I still think the container filesystem is probably making this worse. Even one quick host-side timing would be useful.

#

3. Use long-lived flows where you can

Not a fix, but practical:

keep the gateway running
avoid lots of one-shot CLI calls
use persistent sessions / dashboard when possible

4. Don’t spend hours disabling plugins one by one

At this point I don’t think that’s the best use of your time. You already found the main pattern:

allowlist helps a little
disables barely help
root issue remains

So yes, there are a few more tests/workarounds, but I don’t think there’s a hidden magic config knob here, unfortunately.

If you run that fresh-state-dir test, paste the timings, that would be the most useful next datapoint.

mild hawk Apr 13, 2026, 5:43 AM

#

node@7a440ac70693:~$ OPENCLAW_STATE_DIR=/tmp/oc-empty time openclaw help
bash: time: command not found

toxic swiftBOT Apr 13, 2026, 5:43 AM

#

Ah, yeah, that’s just shell syntax weirdness.

Try this instead:

/usr/bin/time -p env OPENCLAW_STATE_DIR=/tmp/oc-empty openclaw help
/usr/bin/time -p env OPENCLAW_STATE_DIR=/tmp/oc-empty openclaw --help

If /usr/bin/time is missing too, then this also works:

env OPENCLAW_STATE_DIR=/tmp/oc-empty bash -lc 'time openclaw help'
env OPENCLAW_STATE_DIR=/tmp/oc-empty bash -lc 'time openclaw --help'

I mainly care about the openclaw help timing with the fresh state dir. That’s the useful one.

mild hawk Apr 13, 2026, 5:43 AM

#

time is not there. how can i find out where time exists?

toxic swiftBOT Apr 13, 2026, 5:44 AM

#

Try:

type -a time
command -V time
which time

time is often a shell keyword, so type -a time is usually the best one.

If none of those work, you can still time it roughly with:

date +%s
env OPENCLAW_STATE_DIR=/tmp/oc-empty openclaw help
date +%s

#

Crude, but good enough to tell whether it’s 5s vs 40s.

mild hawk Apr 13, 2026, 5:46 AM

#

node@7a440ac70693:~$ env OPENCLAW_STATE_DIR=/tmp/oc-empty bash -lc 'time openclaw help'

🦞 OpenClaw 2026.3.28 (unknown) — Half butler, half debugger, full crustacean.

Usage: openclaw [options] [command]

Options:
  --container <name>   Run the CLI inside a running Podman/Docker container named <name> (default: env OPENCLAW_CONTAINER)
  --dev                Dev profile: isolate state under ~/.openclaw-dev, default gateway port 19001, and shift derived 
<deleted stuff>
real    0m34.442s
user    0m37.500s
sys     0m1.992s
node@7a440ac70693:~$

toxic swiftBOT Apr 13, 2026, 5:47 AM

#

That’s actually a great result, because it narrows it down a lot.

Fresh state dir still being ~34s means:

your normal config/state is not the main culprit
the big cost is in the bundled/container startup path itself
your config probably only adds a few seconds, not the whole 30 to 50s

So the updated picture is:

original: ~50s
trimmed config/allowlist: ~38s
fresh empty state dir: ~34s

That strongly suggests:

core bundled startup/discovery is dominating
container filesystem likely makes it worse

#Openclaw slow

Try a restrictive plugin allowlist

Worth doing

Probably not worth spending a ton of time on

What I would keep first

Smallest practical experiment

1. Try a totally fresh state dir

2. If possible, test outside the container

3. Use long-lived flows where you can

4. Don’t spend hours disabling plugins one by one