Summary
openclaw completion --shell bash (and zsh) takes ~24 seconds because it unnecessarily triggers the plugin loader, which uses jiti to Babel-transpile hundreds of files at runtime.
This makes source <(openclaw completion --shell bash) in .bashrc/.zshrc add ~24s to every new shell session. The tool already detects this pattern via usesSlowDynamicCompletion(), but the completion command itself is the source of the slowness.
Environment
- OpenClaw 2026.2.6-3
- Fedora 43, Linux 6.18.8
- Node.js via Linuxbrew
- Enabled plugins: telegram, slack
Root Cause
When openclaw completion --shell bash runs, the registerCompletionCli action (completion-cli, ~line 148) eagerly registers all subcommands:
const entries = getSubCliEntries();
for (const entry of entries) {
if (entry.name === "completion") continue;
await registerSubCliByName(program, entry.name);
}
Two of these subcommands (pairing and plugins) call loadConfig(), which triggers the full plugin loader. The plugin loader uses jiti (runtime Babel transpiler) to load enabled plugins. Each plugin imports from openclaw/plugin-sdk (791KB, 24K lines), pulling in a massive dependency tree.
CPU Profile Breakdown
| Component |
Time |
| jiti / Babel transpilation |
17.6s (68%) |
| Garbage collection |
2.8s |
| Module loading / resolution |
~3s |
| Everything else |
~2.5s |
| Total |
~26s |
jiti transpiles 423 files to load just the telegram plugin's dependency tree. The slack plugin adds only ~160ms because modules are already cached from telegram.
Profiling Commands Used
# Wall-clock time
time openclaw completion --shell bash > /dev/null
# real 0m23.991s user 0m34.775s sys 0m1.262s
# CPU profile
node --cpu-prof /path/to/openclaw.mjs completion --shell bash > /dev/null
# jiti debug output showing 423 transpilations
# (via createJiti with debug: true)
Suggested Fixes
-
Don't load plugins for completion generation. The completion command only needs the command tree structure (names, options, descriptions) — not live plugin instances. The pairing and plugins subcommands could register their CLI structure without calling loadConfig().
-
Ship pre-compiled plugins. The extensions ship as .ts source files transpiled at runtime via jiti. Pre-compiling them at package build time would eliminate the Babel overhead entirely.
-
Run completion --write-state as a post-install hook and have the default shell integration source from the cached file, avoiding re-generation on every shell startup.
Workaround
Cache the completion output to a file:
openclaw completion --shell bash > ~/.openclaw_completion.bash
# In .bashrc, replace:
# source <(openclaw completion --shell bash)
# with:
source ~/.openclaw_completion.bash
Summary
openclaw completion --shell bash(and zsh) takes ~24 seconds because it unnecessarily triggers the plugin loader, which usesjitito Babel-transpile hundreds of files at runtime.This makes
source <(openclaw completion --shell bash)in.bashrc/.zshrcadd ~24s to every new shell session. The tool already detects this pattern viausesSlowDynamicCompletion(), but the completion command itself is the source of the slowness.Environment
Root Cause
When
openclaw completion --shell bashruns, theregisterCompletionCliaction (completion-cli, ~line 148) eagerly registers all subcommands:Two of these subcommands (
pairingandplugins) callloadConfig(), which triggers the full plugin loader. The plugin loader uses jiti (runtime Babel transpiler) to load enabled plugins. Each plugin imports fromopenclaw/plugin-sdk(791KB, 24K lines), pulling in a massive dependency tree.CPU Profile Breakdown
jiti transpiles 423 files to load just the telegram plugin's dependency tree. The slack plugin adds only ~160ms because modules are already cached from telegram.
Profiling Commands Used
Suggested Fixes
Don't load plugins for completion generation. The completion command only needs the command tree structure (names, options, descriptions) — not live plugin instances. The
pairingandpluginssubcommands could register their CLI structure without callingloadConfig().Ship pre-compiled plugins. The extensions ship as
.tssource files transpiled at runtime via jiti. Pre-compiling them at package build time would eliminate the Babel overhead entirely.Run
completion --write-stateas a post-install hook and have the default shell integration source from the cached file, avoiding re-generation on every shell startup.Workaround
Cache the completion output to a file: