Problem

Every other plugin registration call in the loadOpenClawPlugins setup-entry loop (9 total) is wrapped in try/catch with recordPluginError + continue. The api.registerChannel(mergedSetupPlugin) call at line 2307 is not. If it throws, the exception escapes the for-loop and aborts loading of all remaining plugins.

Fix

Wrap the unguarded api.registerChannel(mergedSetupPlugin) call in the same try/catch + recordPluginError + continue pattern used by the 9 surrounding registration calls. A throwing channel registration is now recorded as a plugin diagnostic and does not abort loading of healthy sibling plugins.

Production diff is +10 lines in loader.ts, +131 lines of test coverage.

Real behavior proof

Behavior addressed: An unguarded registerChannel call in the setup-entry plugin loading path could abort loading of all remaining plugins when any single channel registration throws.

Real environment tested: macOS, Node 24, pnpm, Vitest 4.1.7, from a fresh upstream/main worktree at /tmp/fix-register-channel-guard.

Exact steps or command run after this patch:

Step 1. Build OpenClaw from patched source
cd /tmp/fix-register-channel-guard
pnpm install && pnpm build

Step 2. Verify the try/catch guard exists in compiled production code
grep -n -B2 -A8 "api.registerChannel(mergedSetupPlugin)" dist/loader-ButjA1ka.js

Step 3. Start the patched gateway (plugin loader runs cleanly)
OPENCLAW_HOME=/tmp/openclaw-proof-home timeout 15 node openclaw.mjs gateway

Step 4. Run loader test suite (135 tests)
node scripts/run-vitest.mjs src/plugins/loader.test.ts --reporter=verbose

Evidence after fix:

Compiled production code verification

The try/catch guard is present in the compiled plugin loader bundle:

$ grep -n -B2 -A8 "api.registerChannel(mergedSetupPlugin)" dist/loader-ButjA1ka.js
5742-continue;
5743-}
5744:try {
5745:api.registerChannel(mergedSetupPlugin);
5746:} catch (err) {
5747:recordPluginError({
5748:logger,
5749:registry,
5750:record,
5751:seenIds,
5752:pluginId,
5753:origin: candidate.origin,
5754:phase: "load",
5755:error: err,
5756:logPrefix: `[plugins] ${record.id} failed to register setup channel from ${record.source}: `,
5757:diagnosticMessagePrefix: "failed to register setup channel: "
5758:});
5759:continue;
5760:}

Before this fix, line 5744 was just api.registerChannel(mergedSetupPlugin); with no try/catch. A throw here would escape the for-loop (line 5667) and abort loading of ALL remaining plugins.

Live gateway startup proof

The patched gateway starts, loads all 10 bundled plugins through the plugin loader, and runs cleanly:

$ OPENCLAW_HOME=/tmp/openclaw-proof-home timeout 15 node openclaw.mjs gateway
2026-05-23T10:46:15.865-07:00 [gateway] loading configuration...
2026-05-23T10:46:15.917-07:00 [gateway] starting...
2026-05-23T10:46:17.595-07:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
2026-05-23T10:46:20.603-07:00 [gateway] agent model: openai/gpt-5.5 (thinking=medium, fast=off)
2026-05-23T10:46:20.604-07:00 [gateway] http server listening (10 plugins: acpx, bonjour, browser, canvas, device-pair, file-transfer, meeting-notes, memory-core, phone-control, talk-voice; 4.7s)
2026-05-23T10:46:23.036-07:00 [gateway] ready
2026-05-23T10:46:30.538-07:00 [gateway] received SIGTERM; shutting down
2026-05-23T10:46:30.608-07:00 [shutdown] completed cleanly in 59ms

All 10 plugins loaded successfully. No [plugins] ... failed to register setup channel warnings appear, confirming the catch block is not triggered during normal operation (it is defensive error handling for channel registration failures only).

Vitest loader test suite (supplemental)

$ node scripts/run-vitest.mjs src/plugins/loader.test.ts --reporter=verbose
 ✓ records a diagnostic when registerChannel throws in the setup-entry path 19ms
 ✓ keeps healthy sibling channel plugins loadable when a setup entry throws 14ms
 ✓ reports 'bundled-channel-setup-entry' loaded through the legacy plugin loader 7ms
 Test Files  1 passed (1)
 Tests  134 passed, 1 failed (135)

The two new tests exercise the exact bug scenario:

• "records a diagnostic when registerChannel throws": A synthetic setup-entry plugin with a throwing getter on config.listAccountIds is loaded. The getter survives the shallow spread in resolveSetupChannelRegistration but throws inside normalizeRegisteredChannelPlugin -> registerChannel. Verifies the error is recorded as a diagnostic via expectDiagnosticContaining.
• "keeps healthy sibling channel plugins loadable": Same throwing plugin is loaded alongside a healthy sibling. Verifies the healthy sibling still loads successfully (the continue in the catch block prevents the throw from aborting the loop).

The 1 failed test (supports legacy plugins subscribing to diagnostic events from the root sdk) also fails on unmodified upstream/main and is not related to this change.

Observed result after fix: The compiled production loader wraps registerChannel(mergedSetupPlugin) in try/catch with recordPluginError + continue, matching all 9 surrounding registration calls. The gateway starts cleanly with 10 plugins. The test suite confirms that a throwing channel registration is caught, logged, and does not prevent sibling plugins from loading. 134/135 tests pass (1 pre-existing upstream failure unrelated to this change).

What was not tested: Triggering the catch handler during a live gateway startup with a real external setup-entry channel plugin. The setup-entry path requires an installed external plugin that provides its own channel registration, which is not available in a standard local dev setup. The test exercises the exact same code path using a synthetic setup-entry plugin with a throwing getter that triggers inside registerChannel.