Thanks for the feedback @greptile-apps!

The try-catch fallback in the latest commit handles the runtime case - if the plugin registry isn't initialized, we gracefully fall back to DEFAULT_ACCOUNT_ID, which matches the pre-PR behavior.

You're right that this adds a "heavy" import to resolve-route.ts. A cleaner architecture would be a config-only account resolution path, but that would require:

1. Duplicating account-listing logic for each channel type
2. Or extracting a shared lightweight config parser

For this bugfix PR, the try-catch approach seems like a reasonable tradeoff - it fixes the issue without major refactoring. Happy to discuss if maintainers prefer a different approach.

The key point: in early-init/config-only contexts, falling back to DEFAULT_ACCOUNT_ID is actually correct behavior (same as before this PR).

Can you suggest a fix for this @greptileai?

I see the issue now. Your reasoning about the try-catch is correct, but there's a subtle problem with the fallback behavior that undermines your fix.

When the plugin registry isn't initialized and you fall back to DEFAULT_ACCOUNT_ID ("default"), bindings with omitted accountId will again fail to match channels whose default account is non-literal (like "biz"). Here's why:

In matchesAccountId():

• When match (binding's accountId) is empty/omitted → you check actual === channelDefaultAccountId
• But in early-init contexts, channelDefaultAccountId falls back to "default"
• So a binding with no accountId will only match if actual (the inbound accountId) is literally "default"

This means the bug you're fixing reappears in config-only contexts.

The real tradeoff here:

1. Runtime contexts (plugin registry available): ✅ Fix works
2. Early-init contexts (plugin registry unavailable): ❌ Reverts to broken behavior

A more robust fallback would inspect cfg.channels[channel].accounts directly to find the default account without needing the runtime plugin:

function resolveChannelDefaultAccountIdForRoute(cfg: OpenClawConfig, channel: string): string {
  try {
    const plugin = getChannelPlugin(channel);
    if (!plugin) {
      return DEFAULT_ACCOUNT_ID;
    }
    return normalizeAccountIdFromSessionKey(resolveChannelDefaultAccountId({ plugin, cfg }));
  } catch {
    // Plugin registry not initialized - fall back to config introspection
    const channelCfg = cfg.channels?.[channel];
    if (channelCfg?.accounts && typeof channelCfg.accounts === 'object') {
      const accountIds = Object.keys(channelCfg.accounts);
      if (accountIds.length === 1) {
        return normalizeAccountIdFromSessionKey(accountIds[0]);
      }
    }
    return DEFAULT_ACCOUNT_ID;
  }
}

This preserves your fix even when the plugin registry isn't ready yet.

Thanks @greptileai! Implemented your suggestion - now falls back to config introspection when plugin registry isn't available. If there's exactly one account in cfg.channels[channel].accounts, we use that as the default.

This preserves the fix even in early-init contexts. 🙏

Perfect! The implementation looks solid. You've correctly added the config fallback in resolveChannelDefaultAccountIdForRoute:

• First attempts to use the plugin registry (getChannelPlugin + resolveChannelDefaultAccountId)
• On failure (registry not initialized), inspects cfg.channels[channel].accounts directly
• If exactly one account exists, uses it as the default
• Otherwise falls back to DEFAULT_ACCOUNT_ID

This preserves the fix for the non-literal default account issue (#9198) even during early initialization when the plugin registry isn't available yet. The regression test also confirms the behavior works correctly.

Nice work on the defensive implementation! 🚀