Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix openclaw update exits code 1 on disabled-plugin ClawHub 429 even though core update succeeded; should treat disabled plugins as no-op for sync [2 pull requests, 2 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#73880•Fetched 2026-04-29 06:13:43
View on GitHub
Comments
2
Participants
3
Timeline
9
Reactions
0
Author
islandpreneur007islandpreneur007
Participants
clawsweeper[bot]clawsweeper[bot]islandpreneur007islandpreneur007vincentkocvincentkoc
Timeline (top)
commented ×2cross-referenced ×2mentioned ×2subscribed ×2

openclaw update --channel stable --yes --no-restart --json succeeded on the core package update (4.25 → 4.26) but exited code 1 because the post-update plugin sync hit a ClawHub 429 (rate limit) for the apify plugin. The apify plugin is enabled: false in our config — it should never have been queued for sync.

Per docs.openclaw.ai/cli/update: "Post-update plugin sync failures fail the update result and stop restart follow-up work... fix the plugin install or update error, then rerun openclaw update." Following this guidance would require us to fix the rate-limited update for a plugin we don't even use, OR to remove the plugin entry entirely from config.

Error Message

Per docs.openclaw.ai/cli/update: "Post-update plugin sync failures fail the update result and stop restart follow-up work... fix the plugin install or update error, then rerun openclaw update." Following this guidance would require us to fix the rate-limited update for a plugin we don't even use, OR to remove the plugin entry entirely from config.

  • dist/update-cli-CgKMD06I.js:1797-1810 — post-update-plugins sets overall update error + exits code 1

Root Cause

The current behavior creates pressure to either (a) keep retrying updates against ClawHub until rate-limit clears or (b) remove disabled-plugin entries entirely. Both are friction. Disabled-but-configured is a legitimate state (we may want to enable apify later without re-adding the config block).

Fix Action

Fix / Workaround

Workaround we used

PR fix notes

PR #73902: fix(update): skip disabled plugins during post-update sync

Description (problem / solution / changelog)

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

This PR updates post-update plugin sync so tracked installs that are explicitly disabled in config are resolved before any ClawHub/npm/marketplace update request and are reported as skipped or non-fatal. Enabled plugin update failures, integrity drift, and real install/update errors remain fail-closed.

Preserve disabled install metadata and package-id migration behavior; do not delete disabled installs or lose config. Keep docs unchanged unless the existing CLI update text must explicitly mention disabled tracked plugins.

Credit: report by @islandpreneur007 in #73880.

Validation plan:

  • pnpm test:serial src/plugins/update.test.ts
  • pnpm check:changed

ProjectClownfish replacement details:

  • Cluster: clawsweeper-openclaw-openclaw-73880
  • Source PRs: none
  • Credit: Issue reported by @islandpreneur007 in https://github.com/openclaw/openclaw/issues/73880; credit the report in the PR body and changelog if repo convention supports attribution.; No contributor source PR was hydrated, so no PR branch credit is required.
  • Validation: pnpm test:serial src/plugins/update.test.ts; pnpm check:changed

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/cli/update-cli.test.ts (modified, +4/-0)
  • src/cli/update-cli/update-command.ts (modified, +1/-0)
  • src/plugins/update.test.ts (modified, +145/-0)
  • src/plugins/update.ts (modified, +21/-0)

PR #73970: fix(update): skip disabled plugins during post-update sync

Description (problem / solution / changelog)

Summary

  • skip tracked plugins explicitly disabled in config during post-update plugin sync before npm, ClawHub, or marketplace update checks
  • preserve disabled plugin install records/config while keeping enabled plugin failures and integrity drift fail-closed
  • rebuilds and supersedes #73902 after the original PR became stuck closed by queue-limit automation

Fixes #73880. Supersedes #73902.

Validation

  • Blacksmith Testbox tbx_01kqbgen9xmqs1ma6y7ra2h656: env OPENCLAW_TESTBOX=1 pnpm test:serial src/plugins/update.test.ts src/cli/update-cli.test.ts
  • Blacksmith Testbox tbx_01kqbgen9xmqs1ma6y7ra2h656: env OPENCLAW_TESTBOX=1 pnpm check:changed

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/cli/update-cli.test.ts (modified, +4/-0)
  • src/cli/update-cli/update-command.ts (modified, +1/-0)
  • src/plugins/update.test.ts (modified, +145/-0)
  • src/plugins/update.ts (modified, +21/-0)
RAW_BUFFERClick to expand / collapse

Upstream bug report DRAFT — pending Trent blind-pass

Target: github.com/openclaw/openclaw/issues Status: DRAFT v0 — not filed.

Title

openclaw update exits code 1 on disabled-plugin ClawHub 429 even though core update succeeded; should treat disabled plugins as no-op for sync

Environment

  • OpenClaw 2026.4.25 → 2026.4.26 (be8c246) update
  • Install: pnpm-detected install, real path under .npm-global/lib/node_modules/openclaw
  • Affected plugin: apify (in config but enabled: false)

Summary

openclaw update --channel stable --yes --no-restart --json succeeded on the core package update (4.25 → 4.26) but exited code 1 because the post-update plugin sync hit a ClawHub 429 (rate limit) for the apify plugin. The apify plugin is enabled: false in our config — it should never have been queued for sync.

Per docs.openclaw.ai/cli/update: "Post-update plugin sync failures fail the update result and stop restart follow-up work... fix the plugin install or update error, then rerun openclaw update." Following this guidance would require us to fix the rate-limited update for a plugin we don't even use, OR to remove the plugin entry entirely from config.

Reproduction

  1. Have apify (or any other ClawHub-distributed plugin) in plugins.entries with enabled: false and a config block present
  2. Run openclaw update --channel stable --yes --no-restart --json
  3. If ClawHub returns 429 for the apify update query, the entire update exits code 1

The ClawHub URL queried for the disabled plugin: /api/v1/packages/%40apify%2Fapify-openclaw-plugin/download

Source locations (4.26)

  • dist/update-kKaOeGGE.js:432-440 — ClawHub install/update path
  • dist/update-kKaOeGGE.js:451-456 — update errors pushed into outcomes
  • dist/update-cli-CgKMD06I.js:1274-1287 — JSON plugin update result status includes npm outcomes
  • dist/update-cli-CgKMD06I.js:1313-1325 — non-JSON result status
  • dist/update-cli-CgKMD06I.js:1797-1810 — post-update-plugins sets overall update error + exits code 1

Expected behavior

Plugin sync should:

  • Skip disabled plugins — they're not loaded, not running, sync isn't required for runtime correctness
  • OR: classify plugin-sync failures for disabled plugins as warnings (not fatal), allowing the update to succeed code 0 with a warning surfaced

Workaround we used

Treated the code 1 as non-blocking since:

  • Core 4.26 install completed
  • Apify is disabled (no runtime impact)
  • Doctor passed (with same baseline-of-known-warnings)

Continued with the controlled restart path (--no-restart had been passed, so we did the restart manually). 4.26 is now LIVE and healthy. But this required a judgment call against documented guidance.

Why this matters

The current behavior creates pressure to either (a) keep retrying updates against ClawHub until rate-limit clears or (b) remove disabled-plugin entries entirely. Both are friction. Disabled-but-configured is a legitimate state (we may want to enable apify later without re-adding the config block).

Suggested fix

A disabled plugin present in plugins.entries should be skipped or downgraded to warning during the plugin-sync step. Plugin sync is for plugins that will actually be loaded; it shouldn't gate the entire update on a plugin we're not running.

In the plugin-sync code path (dist/update-cli-CgKMD06I.js:1797-1810), check plugins.entries.<name>.enabled before attempting any ClawHub query. If enabled: false, log skip + move on.

No config option was found in 4.26 to suppress sync for disabled plugins — operators have to either (a) keep retrying until rate-limit clears, or (b) remove the plugin entry entirely from config (loses the keep-disabled-but-configured state).

extent analysis

TL;DR

The openclaw update command should be modified to skip or log a warning for disabled plugins during the plugin-sync step, rather than exiting with code 1 due to a ClawHub 429 rate limit error.

Guidance

  • Check the plugins.entries.<name>.enabled property in the plugin-sync code path to determine if a plugin is disabled before attempting a ClawHub query.
  • If a plugin is disabled, log a skip message and move on to the next plugin, rather than attempting to sync it.
  • Consider adding a config option to suppress sync for disabled plugins, to provide operators with more control over the update process.
  • In the meantime, operators can work around this issue by removing disabled plugin entries from their config, but this may not be desirable if they want to keep the plugin configured but disabled.

Example

// dist/update-cli-CgKMD06I.js:1797-1810
if (plugins.entries[pluginName].enabled) {
  // Attempt ClawHub query and sync
} else {
  console.log(`Skipping sync for disabled plugin ${pluginName}`);
  // Move on to next plugin
}

Notes

This fix assumes that the plugins.entries.<name>.enabled property is a reliable indicator of whether a plugin is disabled. If this property is not always up-to-date or accurate, additional checks may be necessary.

Recommendation

Apply a workaround by modifying the plugin-sync code path to skip disabled plugins, as this will allow operators to update their OpenClaw installation without being blocked by rate limit errors for disabled plugins.

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…

FAQ

Expected behavior

Plugin sync should:

  • Skip disabled plugins — they're not loaded, not running, sync isn't required for runtime correctness
  • OR: classify plugin-sync failures for disabled plugins as warnings (not fatal), allowing the update to succeed code 0 with a warning surfaced
#api#callback error#memory management#API rate limit#retriever error

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 - ✅(Solved) Fix openclaw update exits code 1 on disabled-plugin ClawHub 429 even though core update succeeded; should treat disabled plugins as no-op for sync [2 pull requests, 2 comments, 3 participants]