Skip to content

completion command triggers full plugin loader via jiti, adding ~24s to shell startup #13810

@polcn

Description

@polcn

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

  1. 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().

  2. 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.

  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingstaleMarked as stale due to inactivity

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions