Summary

openclaw doctor --fix migrates top-level channels.telegram.{dmPolicy,allowFrom,groupPolicy} into a new channels.telegram.accounts.default entry. This is correct for installs that started single-account and got promoted, but incorrect for multi-account installs where the top-level fields act as a fallback for the real account entries (e.g. accounts.bot1, accounts.bot2, etc.).

After migration, none of the real bot accounts have allowlist coverage anywhere, and every previously-allowlisted user hits the "access not configured" lockout.

Version

OpenClaw 2026.4.5 (3e72c03), Node v22.22.2, Ubuntu 24.04 ARM64

Reproduction

Starting from a working multi-account Telegram config of this shape:

{
  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "allowlist",
      "allowFrom": ["<USER_ID>"],
      "groupPolicy": "allowlist",
      "accounts": {
        "bot1": { "botToken": "..." },
        "bot2": { "botToken": "..." },
        "bot3": { "botToken": "..." }
      }
    }
  }
}

Run:

sudo -u openclaw -H openclaw doctor --fix

Doctor reports:

Moved channels.telegram single-account top-level values into channels.telegram.accounts.default.

After migration the config becomes:

{
  "channels": {
    "telegram": {
      "enabled": true,
      "accounts": {
        "bot1": { "botToken": "..." },
        "bot2": { "botToken": "..." },
        "bot3": { "botToken": "..." },
        "default": {
          "dmPolicy": "allowlist",
          "allowFrom": ["<USER_ID>"],
          "groupPolicy": "allowlist"
        }
      }
    }
  }
}

After systemctl restart openclaw-gateway, every previously-allowlisted user sending a message to any of the three bots receives:

OpenClaw: access not configured.

Your Telegram user id: <USER_ID>
Pairing code: <CODE>
Ask the bot owner to approve with:
openclaw pairing approve telegram <CODE>

Doctor's own readback after the migration also reports Telegram: not configured, even though the bot providers (bot1, bot2, bot3) start successfully and connect to Telegram normally per the gateway logs.

Expected behavior

Doctor should detect when accounts already contains real entries (not just default) and either:

1. Copy the policy fields into each existing account entry (preserving the fallback semantics across all bots), or
2. Set defaultAccount to whichever account should inherit the legacy fields, rather than creating a fictitious default entry, or
3. Refuse to auto-migrate and emit a warning telling the user to canonicalize manually.

The current behavior silently breaks access control on a category of installs that the migration heuristic does not handle.

Workaround

Restore the pre-migration config from ~/.openclaw/openclaw.json.bak (which doctor writes automatically) and restart the gateway. The 4.5 compat layer handles the legacy shape transparently, so the migration can be deferred indefinitely until either upstream fixes the migration logic or the compat layer is removed.

sudo cp ~/.openclaw/openclaw.json.bak ~/.openclaw/openclaw.json
sudo systemctl restart openclaw-gateway

Detection script for affected installs

sudo cat ~/.openclaw/openclaw.json | python3 -c "
import json, sys
tg = json.load(sys.stdin).get('channels', {}).get('telegram', {})
accts = list(tg.get('accounts', {}).keys())
top_level = [k for k in ('dmPolicy','allowFrom','groupPolicy') if k in tg]
print('AFFECTED' if len(accts) > 1 and top_level else 'safe')
"

Severity

High for affected installs: silent loss of access control, requires manual rollback. The compat layer means there's a clean workaround, so it's not a blocker for the 4.5 upgrade itself, but the migration command is currently a footgun.