openclaw - 💡(How to fix) Fix status fails by loading unconfigured bundled extensions [3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#70226Fetched 2026-04-23 07:27:31
View on GitHub
Comments
3
Participants
3
Timeline
4
Reactions
0
Timeline (top)
commented ×3closed ×1

openclaw status can fail before rendering output when dependencies for unrelated bundled extensions are missing, even if those extensions are not configured.

Root Cause

openclaw status can fail before rendering output when dependencies for unrelated bundled extensions are missing, even if those extensions are not configured.

Fix Action

Fix / Workaround

Happy to test a patch or can provide additional traces if needed.

RAW_BUFFERClick to expand / collapse

Summary

openclaw status can fail before rendering output when dependencies for unrelated bundled extensions are missing, even if those extensions are not configured.

Environment

  • OpenClaw: 2026.4.21 (f788c88)
  • Install type: global npm install
  • OS: Linux

Expected Behavior

  • openclaw status should complete using core runtime and configured channels only.
  • Unconfigured bundled extensions should not be able to crash status rendering.

Actual Behavior

  • Status path eagerly loads bundled extension doctor/contract surfaces across all plugins.
  • If any unconfigured bundled extension has unresolved runtime deps (example: Slack requiring @slack/web-api), openclaw status can fail before output is printed.

Why this appears to happen

From the built runtime code path:

  • doctor contract resolution iterates manifestRegistry.plugins globally
  • each entry attempts to load doctor-contract-api or contract-api through jiti
  • this can pull transitive imports into extension runtime modules, triggering package resolution for extensions that are not configured

Reproduction (high level)

  1. Install OpenClaw globally via npm in an environment where bundled extension runtime deps are not fully staged.
  2. Keep config minimal (do not configure Slack/Feishu/Nostr/etc).
  3. Run openclaw status.
  4. Observe failure due to missing module from an unrelated bundled extension.

Impact

  • Breaks openclaw status reliability and blocks unrelated diagnostics (including gateway/tailscale visibility).
  • Causes cascading "install missing package" loop for extensions users do not use.

Suggested Fix

  • Restrict status/doctor contract loading to configured plugin ids, or
  • Fully isolate/guard contract loading so missing deps in unconfigured extensions are non-fatal, or
  • Ensure bundled runtime dependency staging is guaranteed for global installs before status paths execute.

Happy to test a patch or can provide additional traces if needed.

extent analysis

TL;DR

Restricting status/doctor contract loading to configured plugin IDs or isolating contract loading to prevent missing dependencies in unconfigured extensions from causing failures can resolve the issue.

Guidance

  • Identify and list all configured plugin IDs to understand which extensions should be loaded during openclaw status.
  • Modify the contract resolution logic to only iterate over configured plugins, preventing unnecessary loading of unconfigured extensions.
  • Consider implementing a try-catch block around the contract loading code to catch and log errors, allowing the status command to continue executing even if some extensions have missing dependencies.
  • Review the dependency staging process for global installs to ensure that all required dependencies are installed before executing the status command.

Example

// Pseudo-code example of restricting contract loading to configured plugins
const configuredPlugins = getconfiguredPluginIds();
manifestRegistry.plugins.forEach((plugin) => {
  if (configuredPlugins.includes(plugin.id)) {
    // Load doctor-contract-api or contract-api for configured plugins
    loadContract(plugin);
  }
});

Notes

The suggested fix requires modifications to the OpenClaw codebase, specifically the contract resolution logic. It is essential to test any changes thoroughly to ensure that the fix does not introduce new issues.

Recommendation

Apply a workaround by restricting contract loading to configured plugins, as this approach is more targeted and less likely to introduce new issues compared to fully isolating contract loading or guaranteeing bundled runtime dependency staging.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix status fails by loading unconfigured bundled extensions [3 comments, 3 participants]