Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Production-ready for bot DMs and groups via grammY. Long polling is the default mode; webhook mode is optional.

Pairing

Default DM policy for Telegram is pairing.

Channel troubleshooting

Cross-channel diagnostics and repair playbooks.

Gateway configuration

Full channel config patterns and examples.

Quick setup

1

Create the bot token in BotFather

Open Telegram and chat with @BotFather (confirm the handle is exactly @BotFather).Run /newbot, follow prompts, and save the token.
2

Configure token and DM policy

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "123:abc",
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } },
    },
  },
}
Env fallback: TELEGRAM_BOT_TOKEN=... (default account only). Telegram does not use openclaw channels login telegram; configure token in config/env, then start gateway.
3

Start gateway and approve first DM

openclaw gateway
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
Pairing codes expire after 1 hour.
4

Add the bot to a group

Add the bot to your group, then set channels.telegram.groups and groupPolicy to match your access model.
Token resolution order is account-aware. In practice, config values win over env fallback, and TELEGRAM_BOT_TOKEN only applies to the default account.

Telegram side settings

Telegram bots default to Privacy Mode, which limits what group messages they receive.If the bot must see all group messages, either:
  • disable privacy mode via /setprivacy, or
  • make the bot a group admin.
When toggling privacy mode, remove + re-add the bot in each group so Telegram applies the change.
Admin status is controlled in Telegram group settings.Admin bots receive all group messages, which is useful for always-on group behavior.
  • /setjoingroups to allow/deny group adds
  • /setprivacy for group visibility behavior

Access control and activation

channels.telegram.dmPolicy controls direct message access:
  • pairing (default)
  • allowlist (requires at least one sender ID in allowFrom)
  • open (requires allowFrom to include "*")
  • disabled
dmPolicy: "open" with allowFrom: ["*"] lets any Telegram account that finds or guesses the bot username command the bot. Use it only for intentionally public bots with tightly restricted tools; one-owner bots should use allowlist with numeric user IDs.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. 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).For one-owner bots, prefer dmPolicy: "allowlist" with explicit numeric allowFrom IDs to keep access policy durable in config (instead of depending on previous pairing approvals).Common confusion: DM pairing approval does not mean “this sender is authorized everywhere”. Pairing grants DM access. If no command owner exists yet, the first approved pairing also sets commands.ownerAllowFrom so owner-only commands and exec approvals have an explicit operator account. Group sender authorization still comes from explicit config allowlists. If you want “I am authorized once and both DMs and group commands work”, put your numeric Telegram user ID in channels.telegram.allowFrom; for owner-only commands, make sure commands.ownerAllowFrom contains telegram:<your user id>.

Finding your Telegram user ID

Safer (no third-party bot):
  1. DM your bot.
  2. Run openclaw logs --follow.
  3. Read from.id.
Official Bot API method:
curl "https://api.telegram.org/bot<bot_token>/getUpdates"
Third-party method (less private): @userinfobot or @getidsbot.

Runtime behavior

  • Telegram is owned by the gateway process.
  • Routing is deterministic: Telegram inbound replies back to Telegram (the model does not pick channels).
  • Inbound messages normalize into the shared channel envelope with reply metadata and media placeholders.
  • Group sessions are isolated by group ID. Forum topics append :topic:<threadId> to keep topics isolated.
  • DM messages can carry message_thread_id; OpenClaw routes them with thread-aware session keys and preserves thread ID for replies.
  • Long polling uses grammY runner with per-chat/per-thread sequencing. Overall runner sink concurrency uses agents.defaults.maxConcurrent.
  • Long polling is guarded inside each gateway process so only one active poller can use a bot token at a time. If you still see getUpdates 409 conflicts, another OpenClaw gateway, script, or external poller is likely using the same token.
  • Long-polling watchdog restarts trigger after 120 seconds without completed getUpdates liveness by default. Increase channels.telegram.pollingStallThresholdMs only if your deployment still sees false polling-stall restarts during long-running work. The value is in milliseconds and is allowed from 30000 to 600000; per-account overrides are supported.
  • Telegram Bot API has no read-receipt support (sendReadReceipts does not apply).

Feature reference

OpenClaw can stream partial replies in real time:
  • direct chats: preview message + editMessageText
  • groups/topics: preview message + editMessageText
Requirement:
  • channels.telegram.streaming is off | partial | block | progress (default: partial)
  • progress maps to partial on Telegram (compat with cross-channel naming)
  • streaming.preview.toolProgress controls whether tool/progress updates reuse the same edited preview message (default: true when preview streaming is active)
  • legacy channels.telegram.streamMode and boolean streaming values are detected; run openclaw doctor --fix to migrate them to channels.telegram.streaming.mode
Tool-progress preview updates are the short “Working…” lines shown while tools run, for example command execution, file reads, planning updates, or patch summaries. Telegram keeps these enabled by default to match released OpenClaw behavior from v2026.4.22 and later. To keep the edited preview for answer text but hide tool-progress lines, set:
{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "partial",
        "preview": {
          "toolProgress": false
        }
      }
    }
  }
}
Use streaming.mode: "off" only when you want final-only delivery: Telegram preview edits are disabled and generic tool/progress chatter is suppressed instead of being sent as standalone “Working…” messages. Approval prompts, media payloads, and errors still route through normal final delivery. Use streaming.preview.toolProgress: false when you only want to keep answer preview edits while hiding the tool-progress status lines.For text-only replies:
  • short DM/group/topic previews: OpenClaw keeps the same preview message and performs a final edit in place
  • previews older than about one minute: OpenClaw sends the completed reply as a fresh final message and then cleans up the preview, so Telegram’s visible timestamp reflects completion time instead of the preview creation time
For complex replies (for example media payloads), OpenClaw falls back to normal final delivery and then cleans up the preview message.Preview streaming is separate from block streaming. When block streaming is explicitly enabled for Telegram, OpenClaw skips the preview stream to avoid double-streaming.If native draft transport is unavailable/rejected, OpenClaw automatically falls back to sendMessage + editMessageText.Telegram-only reasoning stream:
  • /reasoning stream sends reasoning to the live preview while generating
  • final answer is sent without reasoning text
Outbound text uses Telegram parse_mode: "HTML".
  • Markdown-ish text is rendered to Telegram-safe HTML.
  • Raw model HTML is escaped to reduce Telegram parse failures.
  • If Telegram rejects parsed HTML, OpenClaw retries as plain text.
Link previews are enabled by default and can be disabled with channels.telegram.linkPreview: false.
Telegram command menu registration is handled at startup with setMyCommands.Native command defaults:
  • commands.native: "auto" enables native commands for Telegram
Add custom command menu entries:
{
  channels: {
    telegram: {
      customCommands: [
        { command: "backup", description: "Git backup" },
        { command: "generate", description: "Create an image" },
      ],
    },
  },
}
Rules:
  • names are normalized (strip leading /, lowercase)
  • valid pattern: a-z, 0-9, _, length 1..32
  • custom commands cannot override native commands
  • conflicts/duplicates are skipped and logged
Notes:
  • custom commands are menu entries only; they do not auto-implement behavior
  • plugin/skill commands can still work when typed even if not shown in Telegram menu
If native commands are disabled, built-ins are removed. Custom/plugin commands may still register if configured.Common setup failures:
  • setMyCommands failed with BOT_COMMANDS_TOO_MUCH means the Telegram menu still overflowed after trimming; reduce plugin/skill/custom commands or disable channels.telegram.commands.native.
  • deleteWebhook, deleteMyCommands, or setMyCommands failing with 404: Not Found while direct Bot API curl commands work can mean channels.telegram.apiRoot was set to the full /bot<TOKEN> endpoint. apiRoot must be only the Bot API root, and openclaw doctor --fix removes an accidental trailing /bot<TOKEN>.
  • getMe returned 401 means Telegram rejected the configured bot token. Update botToken, tokenFile, or TELEGRAM_BOT_TOKEN with the current BotFather token; OpenClaw stops before polling so this is not reported as a webhook cleanup failure.
  • setMyCommands failed with network/fetch errors usually means outbound DNS/HTTPS to api.telegram.org is blocked.

Device pairing commands (device-pair plugin)

When the device-pair plugin is installed:
  1. /pair generates setup code
  2. paste code in iOS app
  3. /pair pending lists pending requests (including role/scopes)
  4. approve the request:
    • /pair approve <requestId> for explicit approval
    • /pair approve when there is only one pending request
    • /pair approve latest for most recent
The setup code carries a short-lived bootstrap token. Built-in bootstrap handoff keeps the primary node token at scopes: []; any handed-off operator token stays bounded to operator.approvals, operator.read, operator.talk.secrets, and operator.write. Bootstrap scope checks are role-prefixed, so that operator allowlist only satisfies operator requests; non-operator roles still need scopes under their own role prefix.If a device retries with changed auth details (for example role/scopes/public key), the previous pending request is superseded and the new request uses a different requestId. Re-run /pair pending before approving.More details: Pairing.
Configure inline keyboard scope:
{
  channels: {
    telegram: {
      capabilities: {
        inlineButtons: "allowlist",
      },
    },
  },
}
Per-account override:
{
  channels: {
    telegram: {
      accounts: {
        main: {
          capabilities: {
            inlineButtons: "allowlist",
          },
        },
      },
    },
  },
}
Scopes:
  • off
  • dm
  • group
  • all
  • allowlist (default)
Legacy capabilities: ["inlineButtons"] maps to inlineButtons: "all".Message action example:
{
  action: "send",
  channel: "telegram",
  to: "123456789",
  message: "Choose an option:",
  buttons: [
    [
      { text: "Yes", callback_data: "yes" },
      { text: "No", callback_data: "no" },
    ],
    [{ text: "Cancel", callback_data: "cancel" }],
  ],
}
Callback clicks are passed to the agent as text: callback_data: <value>
Telegram tool actions include:
  • sendMessage (to, content, optional mediaUrl, replyToMessageId, messageThreadId)
  • react (chatId, messageId, emoji)
  • deleteMessage (chatId, messageId)
  • editMessage (chatId, messageId, content)
  • createForumTopic (chatId, name, optional iconColor, iconCustomEmojiId)
Channel message actions expose ergonomic aliases (send, react, delete, edit, sticker, sticker-search, topic-create).Gating controls:
  • channels.telegram.actions.sendMessage
  • channels.telegram.actions.deleteMessage
  • channels.telegram.actions.reactions
  • channels.telegram.actions.sticker (default: disabled)
Note: edit and topic-create are currently enabled by default and do not have separate channels.telegram.actions.* toggles. Runtime sends use the active config/secrets snapshot (startup/reload), so action paths do not perform ad-hoc SecretRef re-resolution per send.Reaction removal semantics: /tools/reactions
Telegram supports explicit reply threading tags in generated output:
  • [[reply_to_current]] replies to the triggering message
  • [[reply_to:<id>]] replies to a specific Telegram message ID
channels.telegram.replyToMode controls handling:
  • off (default)
  • first
  • all
When reply threading is enabled and the original Telegram text or caption is available, OpenClaw includes a native Telegram quote excerpt automatically. Telegram caps native quote text at 1024 UTF-16 code units, so longer messages are quoted from the start and fall back to a plain reply if Telegram rejects the quote.Note: off disables implicit reply threading. Explicit [[reply_to_*]] tags are still honored.
Forum supergroups:
  • topic session keys append :topic:<threadId>
  • replies and typing target the topic thread
  • topic config path: channels.telegram.groups.<chatId>.topics.<threadId>
General topic (threadId=1) special-case:
  • message sends omit message_thread_id (Telegram rejects sendMessage(...thread_id=1))
  • typing actions still include message_thread_id
Topic inheritance: topic entries inherit group settings unless overridden (requireMention, allowFrom, skills, systemPrompt, enabled, groupPolicy). agentId is topic-only and does not inherit from group defaults.Per-topic agent routing: Each topic can route to a different agent by setting agentId in the topic config. This gives each topic its own isolated workspace, memory, and session. Example:
{
  channels: {
    telegram: {
      groups: {
        "-1001234567890": {
          topics: {
            "1": { agentId: "main" },      // General topic → main agent
            "3": { agentId: "zu" },        // Dev topic → zu agent
            "5": { agentId: "coder" }      // Code review → coder agent
          }
        }
      }
    }
  }
}
Each topic then has its own session key: agent:zu:telegram:group:-1001234567890:topic:3Persistent ACP topic binding: Forum topics can pin ACP harness sessions through top-level typed ACP bindings (bindings[] with type: "acp" and match.channel: "telegram", peer.kind: "group", and a topic-qualified id like -1001234567890:topic:42). Currently scoped to forum topics in groups/supergroups. See ACP Agents.Thread-bound ACP spawn from chat: /acp spawn <agent> --thread here|auto binds the current topic to a new ACP session; follow-ups route there directly. OpenClaw pins the spawn confirmation in-topic. Requires channels.telegram.threadBindings.spawnAcpSessions=true.Template context exposes MessageThreadId and IsForum. DM chats with message_thread_id keep DM routing but use thread-aware session keys.

Audio messages

Telegram distinguishes voice notes vs audio files.
  • default: audio file behavior
  • tag [[audio_as_voice]] in agent reply to force voice-note send
  • inbound voice-note transcripts are framed as machine-generated, untrusted text in the agent context; mention detection still uses the raw transcript so mention-gated voice messages continue to work.
Message action example:
{
  action: "send",
  channel: "telegram",
  to: "123456789",
  media: "https://example.com/voice.ogg",
  asVoice: true,
}

Video messages

Telegram distinguishes video files vs video notes.Message action example:
{
  action: "send",
  channel: "telegram",
  to: "123456789",
  media: "https://example.com/video.mp4",
  asVideoNote: true,
}
Video notes do not support captions; provided message text is sent separately.

Stickers

Inbound sticker handling:
  • static WEBP: downloaded and processed (placeholder <media:sticker>)
  • animated TGS: skipped
  • video WEBM: skipped
Sticker context fields:
  • Sticker.emoji
  • Sticker.setName
  • Sticker.fileId
  • Sticker.fileUniqueId
  • Sticker.cachedDescription
Sticker cache file:
  • ~/.openclaw/telegram/sticker-cache.json
Stickers are described once (when possible) and cached to reduce repeated vision calls.Enable sticker actions:
{
  channels: {
    telegram: {
      actions: {
        sticker: true,
      },
    },
  },
}
Send sticker action:
{
  action: "sticker",
  channel: "telegram",
  to: "123456789",
  fileId: "CAACAgIAAxkBAAI...",
}
Search cached stickers:
{
  action: "sticker-search",
  channel: "telegram",
  query: "cat waving",
  limit: 5,
}
Telegram reactions arrive as message_reaction updates (separate from message payloads).When enabled, OpenClaw enqueues system events like:
  • Telegram reaction added: 👍 by Alice (@alice) on msg 42
Config:
  • channels.telegram.reactionNotifications: off | own | all (default: own)
  • channels.telegram.reactionLevel: off | ack | minimal | extensive (default: minimal)
Notes:
  • own means user reactions to bot-sent messages only (best-effort via sent-message cache).
  • Reaction events still respect Telegram access controls (dmPolicy, allowFrom, groupPolicy, groupAllowFrom); unauthorized senders are dropped.
  • Telegram does not provide thread IDs in reaction updates.
    • non-forum groups route to group chat session
    • forum groups route to the group general-topic session (:topic:1), not the exact originating topic
allowed_updates for polling/webhook include message_reaction automatically.
ackReaction sends an acknowledgement emoji while OpenClaw is processing an inbound message.Resolution order:
  • channels.telegram.accounts.<accountId>.ackReaction
  • channels.telegram.ackReaction
  • messages.ackReaction
  • agent identity emoji fallback (agents.list[].identity.emoji, else ”👀”)
Notes:
  • Telegram expects unicode emoji (for example ”👀”).
  • Use "" to disable the reaction for a channel or account.
Channel config writes are enabled by default (configWrites !== false).Telegram-triggered writes include:
  • group migration events (migrate_to_chat_id) to update channels.telegram.groups
  • /config set and /config unset (requires command enablement)
Disable:
{
  channels: {
    telegram: {
      configWrites: false,
    },
  },
}
Default is long polling. For webhook mode set channels.telegram.webhookUrl and channels.telegram.webhookSecret; optional webhookPath, webhookHost, webhookPort (defaults /telegram-webhook, 127.0.0.1, 8787).The local listener binds to 127.0.0.1:8787. For public ingress, either put a reverse proxy in front of the local port or set webhookHost: "0.0.0.0" intentionally.Webhook mode validates request guards, the Telegram secret token, and the JSON body before returning 200 to Telegram. OpenClaw then processes the update asynchronously through the same per-chat/per-topic bot lanes used by long polling, so slow agent turns do not hold Telegram’s delivery ACK.
  • channels.telegram.textChunkLimit default is 4000.
  • channels.telegram.chunkMode="newline" prefers paragraph boundaries (blank lines) before length splitting.
  • channels.telegram.mediaMaxMb (default 100) caps inbound and outbound Telegram media size.
  • channels.telegram.timeoutSeconds overrides Telegram API client timeout (if unset, grammY default applies).
  • channels.telegram.pollingStallThresholdMs defaults to 120000; tune between 30000 and 600000 only for false-positive polling-stall restarts.
  • group context history uses channels.telegram.historyLimit or messages.groupChat.historyLimit (default 50); 0 disables.
  • reply/quote/forward supplemental context is currently passed as received.
  • Telegram allowlists primarily gate who can trigger the agent, not a full supplemental-context redaction boundary.
  • DM history controls:
    • channels.telegram.dmHistoryLimit
    • channels.telegram.dms["<user_id>"].historyLimit
  • channels.telegram.retry config applies to Telegram send helpers (CLI/tools/actions) for recoverable outbound API errors.
CLI send target can be numeric chat ID or username:
openclaw message send --channel telegram --target 123456789 --message "hi"
openclaw message send --channel telegram --target @name --message "hi"
Telegram polls use openclaw message poll and support forum topics:
openclaw message poll --channel telegram --target 123456789 \
  --poll-question "Ship it?" --poll-option "Yes" --poll-option "No"
openclaw message poll --channel telegram --target -1001234567890:topic:42 \
  --poll-question "Pick a time" --poll-option "10am" --poll-option "2pm" \
  --poll-duration-seconds 300 --poll-public
Telegram-only poll flags:
  • --poll-duration-seconds (5-600)
  • --poll-anonymous
  • --poll-public
  • --thread-id for forum topics (or use a :topic: target)
Telegram send also supports:
  • --presentation with buttons blocks for inline keyboards when channels.telegram.capabilities.inlineButtons allows it
  • --pin or --delivery '{"pin":true}' to request pinned delivery when the bot can pin in that chat
  • --force-document to send outbound images and GIFs as documents instead of compressed photo or animated-media uploads
Action gating:
  • channels.telegram.actions.sendMessage=false disables outbound Telegram messages, including polls
  • channels.telegram.actions.poll=false disables Telegram poll creation while leaving regular sends enabled
Telegram supports exec approvals in approver DMs and can optionally post prompts in the originating chat or topic. Approvers must be numeric Telegram user IDs.Config path:
  • channels.telegram.execApprovals.enabled (auto-enables when at least one approver is resolvable)
  • channels.telegram.execApprovals.approvers (falls back to numeric owner IDs from commands.ownerAllowFrom)
  • channels.telegram.execApprovals.target: dm (default) | channel | both
  • agentFilter, sessionFilter
channels.telegram.allowFrom, groupAllowFrom, and defaultTo control who can talk to the bot and where it sends normal replies. They do not make someone an exec approver. The first approved DM pairing bootstraps commands.ownerAllowFrom when no command owner exists yet, so the one-owner setup still works without duplicating IDs under execApprovals.approvers.Channel delivery shows the command text in the chat; only enable channel or both in trusted groups/topics. When the prompt lands in a forum topic, OpenClaw preserves the topic for the approval prompt and the follow-up. Exec approvals expire after 30 minutes by default.Inline approval buttons also require channels.telegram.capabilities.inlineButtons to allow the target surface (dm, group, or all). Approval IDs prefixed with plugin: resolve through plugin approvals; others resolve through exec approvals first.See Exec approvals.

Error reply controls

When the agent encounters a delivery or provider error, Telegram can either reply with the error text or suppress it. Two config keys control this behavior:
KeyValuesDefaultDescription
channels.telegram.errorPolicyreply, silentreplyreply sends a friendly error message to the chat. silent suppresses error replies entirely.
channels.telegram.errorCooldownMsnumber (ms)60000Minimum time between error replies to the same chat. Prevents error spam during outages.
Per-account, per-group, and per-topic overrides are supported (same inheritance as other Telegram config keys).
{
  channels: {
    telegram: {
      errorPolicy: "reply",
      errorCooldownMs: 120000,
      groups: {
        "-1001234567890": {
          errorPolicy: "silent", // suppress errors in this group
        },
      },
    },
  },
}

Troubleshooting

  • If requireMention=false, Telegram privacy mode must allow full visibility.
    • BotFather: /setprivacy -> Disable
    • then remove + re-add bot to group
  • openclaw channels status warns when config expects unmentioned group messages.
  • openclaw channels status --probe can check explicit numeric group IDs; wildcard "*" cannot be membership-probed.
  • quick session test: /activation always.
  • when channels.telegram.groups exists, group must be listed (or include "*")
  • verify bot membership in group
  • review logs: openclaw logs --follow for skip reasons
  • authorize your sender identity (pairing and/or numeric allowFrom)
  • command authorization still applies even when group policy is open
  • setMyCommands failed with BOT_COMMANDS_TOO_MUCH means the native menu has too many entries; reduce plugin/skill/custom commands or disable native menus
  • setMyCommands failed with network/fetch errors usually indicates DNS/HTTPS reachability issues to api.telegram.org
  • getMe returned 401 is a Telegram authentication failure for the configured bot token.
  • Re-copy or regenerate the bot token in BotFather, then update channels.telegram.botToken, channels.telegram.tokenFile, channels.telegram.accounts.<id>.botToken, or TELEGRAM_BOT_TOKEN for the default account.
  • deleteWebhook 401 Unauthorized during startup is also an auth failure; treating it as “no webhook exists” would only defer the same bad-token failure to later API calls.
  • Node 22+ + custom fetch/proxy can trigger immediate abort behavior if AbortSignal types mismatch.
  • Some hosts resolve api.telegram.org to IPv6 first; broken IPv6 egress can cause intermittent Telegram API failures.
  • If logs include TypeError: fetch failed or Network request for 'getUpdates' failed!, OpenClaw now retries these as recoverable network errors.
  • If logs include Polling stall detected, OpenClaw restarts polling and rebuilds the Telegram transport after 120 seconds without completed long-poll liveness by default.
  • Increase channels.telegram.pollingStallThresholdMs only when long-running getUpdates calls are healthy but your host still reports false polling-stall restarts. Persistent stalls usually point to proxy, DNS, IPv6, or TLS egress issues between the host and api.telegram.org.
  • On VPS hosts with unstable direct egress/TLS, route Telegram API calls through channels.telegram.proxy:
channels:
  telegram:
    proxy: socks5://<user>:<password>@proxy-host:1080
  • Node 22+ defaults to autoSelectFamily=true (except WSL2) and dnsResultOrder=ipv4first.
  • If your host is WSL2 or explicitly works better with IPv4-only behavior, force family selection:
channels:
  telegram:
    network:
      autoSelectFamily: false
  • RFC 2544 benchmark-range answers (198.18.0.0/15) are already allowed for Telegram media downloads by default. If a trusted fake-IP or transparent proxy rewrites api.telegram.org to some other private/internal/special-use address during media downloads, you can opt in to the Telegram-only bypass:
channels:
  telegram:
    network:
      dangerouslyAllowPrivateNetwork: true
  • The same opt-in is available per account at channels.telegram.accounts.<accountId>.network.dangerouslyAllowPrivateNetwork.
  • If your proxy resolves Telegram media hosts into 198.18.x.x, leave the dangerous flag off first. Telegram media already allows the RFC 2544 benchmark range by default.
channels.telegram.network.dangerouslyAllowPrivateNetwork weakens Telegram media SSRF protections. Use it only for trusted operator-controlled proxy environments such as Clash, Mihomo, or Surge fake-IP routing when they synthesize private or special-use answers outside the RFC 2544 benchmark range. Leave it off for normal public internet Telegram access.
  • Environment overrides (temporary):
    • OPENCLAW_TELEGRAM_DISABLE_AUTO_SELECT_FAMILY=1
    • OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY=1
    • OPENCLAW_TELEGRAM_DNS_RESULT_ORDER=ipv4first
  • Validate DNS answers:
dig +short api.telegram.org A
dig +short api.telegram.org AAAA
More help: Channel troubleshooting.

Configuration reference

Primary reference: Configuration reference - Telegram.
  • startup/auth: enabled, botToken, tokenFile, accounts.* (tokenFile must point to a regular file; symlinks are rejected)
  • access control: dmPolicy, allowFrom, groupPolicy, groupAllowFrom, groups, groups.*.topics.*, top-level bindings[] (type: "acp")
  • exec approvals: execApprovals, accounts.*.execApprovals
  • command/menu: commands.native, commands.nativeSkills, customCommands
  • threading/replies: replyToMode
  • streaming: streaming (preview), streaming.preview.toolProgress, blockStreaming
  • formatting/delivery: textChunkLimit, chunkMode, linkPreview, responsePrefix
  • media/network: mediaMaxMb, timeoutSeconds, pollingStallThresholdMs, retry, network.autoSelectFamily, network.dangerouslyAllowPrivateNetwork, proxy
  • custom API root: apiRoot (Bot API root only; do not include /bot<TOKEN>)
  • webhook: webhookUrl, webhookSecret, webhookPath, webhookHost
  • actions/capabilities: capabilities.inlineButtons, actions.sendMessage|editMessage|deleteMessage|reactions|sticker
  • reactions: reactionNotifications, reactionLevel
  • errors: errorPolicy, errorCooldownMs
  • writes/history: configWrites, historyLimit, dmHistoryLimit, dms.*.historyLimit
Multi-account precedence: when two or more account IDs are configured, set channels.telegram.defaultAccount (or include channels.telegram.accounts.default) to make default routing explicit. Otherwise OpenClaw falls back to the first normalized account ID and openclaw doctor warns. Named accounts inherit channels.telegram.allowFrom / groupAllowFrom, but not accounts.default.* values.

Pairing

Pair a Telegram user to the gateway.

Groups

Group and topic allowlist behavior.

Channel routing

Route inbound messages to agents.

Security

Threat model and hardening.

Multi-agent routing

Map groups and topics to agents.

Troubleshooting

Cross-channel diagnostics.