When tools.catalog is called from the frontend, it triggers ensureStandalonePluginToolRegistryLoaded with surface=channel and toolDiscovery=true. In toolDiscovery mode, the loaded registry contains no channels, but installStandaloneRegistry still overwrites the pinned channel registry with this empty registry, causing 'Outbound not configured for channel: feishu' errors.

Add a guard: if toolDiscovery is enabled and the registry has no channels, return early before the surface switch that would overwrite the channel registry.

Summary

What problem does this PR solve?

• After gateway restart, any frontend page load calls tools.catalog, which triggers ensureStandalonePluginToolRegistryLoaded(surface="channel", toolDiscovery=true). In toolDiscovery mode the loaded registry has zero channels, but installStandaloneRegistry still calls pinActivePluginChannelRegistry with that empty registry, overwriting the pinned channel registry that was correctly set during gateway startup. This causes all outbound channel operations (feishu, discord, slack, etc.) to fail with "Outbound not configured for channel: ".

Why does this matter now?

• This is a reliability regression: every time a user opens the frontend UI after a gateway restart, the channel registry is silently wiped. Any cron jobs, outbound messages, or channel-dependent features break until the next gateway restart — and even then, opening the frontend again re-triggers the wipe.

What is the intended outcome?

• When toolDiscovery=true and the loaded registry has no channels, installStandaloneRegistry returns early after setActivePluginRegistry but before the switch (surface) block that would overwrite the pinned channel registry. The active registry is still updated (preserving tool discovery behavior), but the channel registry pin is left intact.

What is intentionally out of scope?

• Changes to ensureStandalonePluginToolRegistryLoaded's hardcoded surface: "channel" parameter.
• Changes to the cache key logic that causes toolDiscovery and full-mode loads to produce different cache keys.
• Defensive fallbacks in getActivePluginChannelRegistry or the outbound delivery path.
• The params.manifestRecord.manifest.id vs params.manifestRecord.id inconsistency in loader.ts (separate issue).

What does success look like?

• After gateway restart, opening the frontend and calling tools.catalog no longer wipes the channel registry. Outbound channel operations (feishu, etc.) continue to work without requiring a second restart.

What should reviewers focus on?

• Whether the guard condition toolDiscovery && registry.channels.length === 0 is the correct and complete check, or if there are other scenarios where a channel-less registry should still be allowed to overwrite the pin.
• Whether returning after setActivePluginRegistry but before the switch (surface) block could break any downstream consumers that expect the channel pin to be updated even in toolDiscovery mode.

Linked context

Which issue does this close?

Closes #

Which issues, PRs, or discussions are related?

Related #

Was this requested by a maintainer or owner?

No — discovered through live debugging of a production incident.

Real behavior proof

• Behavior or issue addressed:
  tools.catalog standalone tool-discovery loads should not overwrite the startup-pinned channel registry with an empty registry.

• Real environment tested:
  Real OpenClaw gateway setup with a configured feishu channel.

• Exact steps or command run after this patch:

  1. Configure the feishu channel in a real OpenClaw environment.
  2. Run openclaw gateway call channels.status.
  3. Confirm channels.status returns the configured/running feishu channel snapshot.
  4. Run openclaw gateway call tools.catalog.
  5. Run openclaw gateway call channels.status again.
  6. Compare the channel snapshot before and after tools.catalog.

• Evidence after fix:
  The same real environment shows the regression before the fix and stable channel state after the fix.

  Real terminal output before/after fix

  # Before fix: channels.status is healthy before tools.catalog
  $ openclaw gateway call channels.status
  {
    "channelOrder": ["feishu"],
    "channelLabels": {
      "feishu": "Feishu"
    },
    "channelMeta": [
      {
        "id": "feishu",
        "label": "Feishu",
        "detailLabel": "Lark/Feishu (飞书)"
      }
    ],
    "channels": {
      "feishu": {
        "configured": true,
        "running": true,
        "lastError": null
      }
    },
    "channelAccounts": {
      "feishu": [
        {
          "accountId": "a-mppjjfy4ydga2m",
          "configured": true,
          "running": true,
          "brand": "feishu"
        },
        {
          "accountId": "default",
          "configured": true,
          "running": true,
          "brand": "feishu"
        }
      ]
    },
    "channelDefaultAccountId": {
      "feishu": "a-mppjjfy4ydga2m"
    }
  }
  
  # Before fix: tools.catalog triggers the bug
  $ openclaw gateway call tools.catalog
  { "...": "tools catalog returned" }
  
  $ openclaw gateway call channels.status
  {
    "channelOrder": [],
    "channelLabels": {},
    "channelMeta": [],
    "channels": {},
    "channelAccounts": {},
    "channelDefaultAccountId": {}
  }
  
  # After fix: tools.catalog no longer wipes the pinned channel registry
  $ openclaw gateway call tools.catalog
  { "...": "tools catalog returned" }
  
  $ openclaw gateway call channels.status
  {
    "channelOrder": ["feishu"],
    "channelLabels": {
      "feishu": "Feishu"
    },
    "channelMeta": [
      {
        "id": "feishu",
        "label": "Feishu",
        "detailLabel": "Lark/Feishu (飞书)"
      }
    ],
    "channels": {
      "feishu": {
        "configured": true,
        "running": true,
        "lastError": null
      }
    },
    "channelAccounts": {
      "feishu": [
        {
          "accountId": "a-mppjjfy4ydga2m",
          "configured": true,
          "running": true,
          "brand": "feishu"
        },
        {
          "accountId": "default",
          "configured": true,
          "running": true,
          "brand": "feishu"
        }
      ]
    },
    "channelDefaultAccountId": {
      "feishu": "a-mppjjfy4ydga2m"
    }
  }
  

• Observed result after fix:
  After the patch, tools.catalog no longer clears the pinned channel registry. channels.status continues to return the configured/running feishu channel snapshot after tools.catalog runs.

• What was not tested:
  I did not include a screen recording or multi-host deployment proof in this PR body.

• Proof limitations or environment constraints:
  This proof is from a real manually configured environment and focuses on the feishu path that reproduced the bug.

Tests and validation

Which commands did you run?

• pnpm build — verified the patch compiles without errors
• Manual integration test on live deployment with diagnostic logging

What regression coverage was added or updated?

• None — this is a guard against a runtime state corruption that is difficult to reproduce in unit tests without mocking the entire plugin loading pipeline

What failed before this fix, if known?

• All outbound channel operations (feishu message delivery, cron.run) failed with "Outbound not configured for channel: feishu" after frontend page load triggered tools.catalog

If no test was added, why not?

• The bug requires a full gateway runtime with plugin loading, channel binding, and a frontend WebSocket call to reproduce. The existing test infrastructure for standalone-runtime-registry-loader does not cover the interaction between toolDiscovery mode and pinActivePluginChannelRegistry. Adding a meaningful unit test would require significant mocking of the plugin loading pipeline, which may not provide reliable regression coverage.

Risk checklist

Did user-visible behavior change? (Yes/No)

No — the fix prevents silent state corruption; no user-facing API or output changes

Did config, environment, or migration behavior change? (Yes/No)

No

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

No

What is the highest-risk area?

• The guard could theoretically prevent a legitimate channel registry update in toolDiscovery mode. However, toolDiscovery mode by design does not load channel surfaces (runtimeChannel=false), so a registry with channels.length === 0 in toolDiscovery mode is expected behavior, not a missing update.

How is that risk mitigated?

• The guard only applies when both conditions are true: toolDiscovery=true AND registry.channels.length === 0. In full mode (toolDiscovery=false), the channel registry is still updated normally. In toolDiscovery mode with a non-empty channels array (which should not happen but is theoretically possible), the registry would also be updated normally.

Current review state

What is the next action?

• Awaiting maintainer review

What is still waiting on author, maintainer, CI, or external proof?

• CI checks need to pass; maintainer review needed

Which bot or reviewer comments were addressed?

• N/A — first submission

$ pnpm test src/plugins/runtime/standalone-runtime-registry-loader.test.ts

 RUN  v4.1.7 /Users/bytedance/Code/openclaw

 ✓ |plugins| src/plugins/runtime/standalone-runtime-registry-loader.test.ts (3 tests) 14ms
     ✓ reuses a compatible gateway startup registry for gateway-bindable dispatch load options 10ms
     ✓ loads a fresh registry when dispatch config is not startup-compatible 2ms
     ✓ does not pin a tool-discovery registry when channels are empty 2ms

 Test Files  1 passed (1)
      Tests  3 passed (3)
   Start at  20:32:02
   Duration  1.15s (transform 692ms, setup 110ms, import 950ms, tests 14ms, environment 0ms)

[test] starting test/vitest/vitest.plugins.config.ts
[test] passed 1 Vitest shard in 3.45s