chore(sync): mirror docs from openclaw/openclaw@0ce5e358d4
This commit is contained in:
parent
5fe1d75bb9
commit
b2489a70fb
@ -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"
|
||||
}
|
||||
|
||||
@ -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).
|
||||
|
||||
|
||||
@ -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):
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user