Summary

• Problem: listChannelCatalogEntries in src/plugins/channel-catalog-registry.ts calls discoverOpenClawPlugins without forwarding installRecords. As a result, channels installed via openclaw plugins install <npm-spec> are absent from the CLI channel catalog—openclaw channels add --channel <id> and openclaw channels login --channel <id> report Unsupported channel: <id> / Unknown channel: <id> even though the ledger entry under ~/.openclaw/plugins/installs.json is healthy.
• Why it matters: Every third-party npm-installed channel plugin is unreachable through the channels CLI surface. Bundled plugins (qqbot, telegram, slack, etc.) take the stock discovery path and were unaffected, which masked the regression.
• What changed: listChannelCatalogEntries now lazy-loads the persisted plugin install ledger via loadInstalledPluginIndexInstallRecordsSync when the caller does not specify origin === "bundled", and forwards the records to discovery. Bundled-only callers continue to skip the disk read. Callers that already hold a record map can pass it via the new optional installRecords parameter to skip the lazy load. Reader errors fall back silently to "no install records" (no behavioural regression).
• What did NOT change (scope boundary): Other discoverOpenClawPlugins consumers (bundled-capability-runtime.ts, bundled-sources.ts, config-contracts.ts) are untouched—they target bundled-only paths or pre-load records elsewhere. No public manifest/contract types changed. manifest-registry.ts, loader.ts, and installed-plugin-index-registry.ts were already forwarding installRecords correctly; this PR only reaches feature parity for the channel-catalog-registry path.

This PR also registers `@tencent-weixin/openclaw-weixin` in `scripts/lib/official-external-channel-catalog.json` so the channel appears in onboarding flows that consult the catalog directly (mirroring the WeCom and Yuanbao entries).

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra (catalog entry addition)

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #
• This PR fixes a bug or regression

Root Cause

• Root cause: `listChannelCatalogEntries` predates the move to the persisted install ledger as the canonical source for npm-installed plugin discovery (see `installed-plugin-index-registry.ts`, `manifest-registry.ts`, and `loader.ts`, which all forward `installRecords` to `discoverOpenClawPlugins`). The catalog-registry consumer was missed during that migration.
• Missing detection / guardrail: No test asserted that `listChannelCatalogEntries` could see npm-installed plugins. The closest existing coverage (`bundled-channel-catalog-read.fail-soft.test.ts`) only exercises the bundled soft-fail path; the `discoverOpenClawPlugins` tests don't reach this consumer.
• Contributing context: The CLI surface (`channels add`, `channels login`) reaches `listChannelCatalogEntries` indirectly through `listChannelPluginCatalogEntries` in `src/channels/plugins/catalog.ts`. The bundled discovery path stays green even with this bug, so bundled channel tests didn't catch it.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
• Target test or file: `src/plugins/channel-catalog-registry.test.ts` (new)
• Scenario the test should lock in: When `origin !== "bundled"`, `listChannelCatalogEntries` MUST forward install records to `discoverOpenClawPlugins`. When `origin === "bundled"`, the ledger MUST NOT be read. Caller-supplied `installRecords` MUST replace the lazy load. Empty ledgers and reader errors MUST omit `installRecords` from the discovery call without throwing.
• Why this is the smallest reliable guardrail: The bug was a silently-omitted argument; the test mocks both `discoverOpenClawPlugins` and the ledger reader, then asserts the call signature, so any future regression that drops the parameter again surfaces immediately.
• Existing test that already covers this: None.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• `openclaw channels add --channel ` and `openclaw channels login --channel ` now resolve npm-installed channel plugins recorded in `~/.openclaw/plugins/installs.json`. Previously they returned `Unsupported channel: ` / `Unknown channel: ` for any third-party plugin.
• `@tencent-weixin/openclaw-weixin` appears in the official external channel catalog (`source: "external"`, `kind: "channel"`).

Diagram

```text
Before:
channels add/login → listChannelCatalogEntries → discoverOpenClawPlugins({ workspaceDir, env })
^ no installRecords; npm-installed plugins invisible to catalog

After:
channels add/login → listChannelCatalogEntries
├─ if origin !== "bundled": loadInstalledPluginIndexInstallRecordsSync()
└─ discoverOpenClawPlugins({ workspaceDir, env, installRecords })
^ npm-installed plugins discoverable
```

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No (`~/.openclaw/plugins/installs.json` was already read by sibling discovery callers)
• If any `Yes`, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux (TencentOS, x64)
• Runtime/container: Node v22.x, host source checkout via `pnpm install && pnpm start`
• Model/provider: N/A
• Integration/channel: `openclaw-weixin`
• Relevant config (redacted): `OPENCLAW_STATE_DIR=/tmp/openclaw-fix-verify`

Steps

1. `pnpm install`
2. `OPENCLAW_STATE_DIR=/tmp/openclaw-fix-verify pnpm start plugins install @tencent-weixin/openclaw-weixin`
3. `OPENCLAW_STATE_DIR=/tmp/openclaw-fix-verify pnpm start channels add --channel openclaw-weixin --account default ...`

Expected

• Channel resolves; the per-channel `applyAccountConfig` flow runs.

Actual

• Before fix: `Unknown channel: openclaw-weixin`.
• After fix: channel resolves and the add flow proceeds.

Evidence

• Failing test/log before + passing after — 5 unit cases in `src/plugins/channel-catalog-registry.test.ts` (all pass via `npx vitest run src/plugins/channel-catalog-registry.test.ts`).
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification

• Verified scenarios:
  • Local source checkout on Linux. Installed `@tencent-weixin/[email protected]` against an isolated `OPENCLAW_STATE_DIR`; ledger entry verified; `pnpm start channels add --channel openclaw-weixin` now resolves the channel through the patched catalog path.
  • 5/5 unit tests in the new `channel-catalog-registry.test.ts` cover lazy-load, bundled-skip, caller-supplied, empty-ledger, and reader-error paths.
• Edge cases checked:
  • Bundled-only callers continue to skip the ledger read (no extra disk I/O).
  • Reader failure does not throw — silently falls back to no `installRecords`.
• What I did NOT verify:
  • Non-Linux environments (macOS, Windows).
  • End-to-end UX in onboarding/control-ui surfaces (beyond the channels CLI).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: `loadInstalledPluginIndexInstallRecordsSync` performs a synchronous disk read on every catalog list call when `origin` is unspecified. This is consistent with sibling discovery consumers (`installed-plugin-index-registry.ts`, `loader.ts`, etc.) but adds one ledger read on hot CLI paths like `channels add`.
  • Mitigation: Bundled-only callers skip the read. Callers that already loaded records can pass `installRecords` to avoid the duplicate read.
• Risk: The new catalog entry intentionally omits `expectedIntegrity` (`npmSpec` is unpinned, matching the `@openclaw/*` entries). External-source entries like `wecom` and `yuanbao` are version-pinned.
  • Mitigation: Treat the entry as discovery metadata only; install integrity is enforced by the install ledger, not the catalog file. We can pin the spec + integrity in a follow-up once a stable release line is in place.