chore(sync): mirror docs from openclaw/openclaw@0ce5e358d4

This commit is contained in:
openclaw-docs-sync[bot] 2026-04-20 04:34:12 +00:00
parent 5fe1d75bb9
commit b2489a70fb
3 changed files with 4 additions and 4 deletions

View File

@ -1,5 +1,5 @@
{
"repository": "openclaw/openclaw",
"sha": "1d5b58ac18f7e5c613f9bd8d6a18ff49319cd5ad",
"syncedAt": "2026-04-20T04:15:38.579Z"
"sha": "0ce5e358d4b52e0551bfb46415b15c32fbfa166f",
"syncedAt": "2026-04-20T04:34:12.129Z"
}

View File

@ -115,7 +115,7 @@ Token resolution order is account-aware. In practice, config values win over env
`channels.telegram.allowFrom` accepts numeric Telegram user IDs. `telegram:` / `tg:` prefixes are accepted and normalized.
`dmPolicy: "allowlist"` with empty `allowFrom` blocks all DMs and is rejected by config validation.
Onboarding accepts `@username` input and resolves it to numeric IDs.
Setup asks for numeric user IDs only.
If you upgraded and your config contains `@username` allowlist entries, run `openclaw doctor --fix` to resolve them (best-effort; requires a Telegram bot token).
If you previously relied on pairing-store allowlist files, `openclaw doctor --fix` can recover entries into `channels.telegram.allowFrom` in allowlist flows (for example when `dmPolicy: "allowlist"` has no explicit IDs yet).

View File

@ -767,7 +767,7 @@ for usage/billing and raise limits as needed.
<Accordion title="Telegram: what goes in allowFrom?">
`channels.telegram.allowFrom` is **the human sender's Telegram user ID** (numeric). It is not the bot username.
Onboarding accepts `@username` input and resolves it to a numeric ID, but OpenClaw authorization uses numeric IDs only.
Setup asks for numeric user IDs only. If you already have legacy `@username` entries in config, `openclaw doctor --fix` can try to resolve them.
Safer (no third-party bot):