Telegram: how to check incoming message from group? | Friends of the Crustacean 🦞🤝 | Page 1

topaz jewelBOT Mar 4, 2026, 3:24 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

mild harborBOT Mar 4, 2026, 3:26 AM

#

openclaw logs --follow tails the Gateway’s file log (via RPC), so it should include Telegram… but it’s easy to miss in the noise.

A better way to confirm Telegram activity is to filter to channel logs:

openclaw channels status
openclaw channels logs --channel telegram

If you DM the bot (or send a group message) and still see nothing in channels logs, then one of these is usually true:

You’re tailing logs on the wrong Gateway host (common in remote mode)
- Check what you’re actually connected to:
```
openclaw gateway status
```

#

Telegram isn’t actually running / configured in the Gateway config the service is using
- openclaw gateway status will also hint if Config (cli) vs Config (service) differ.

If you want to make Telegram super chatty for debugging, run the gateway once with debug logging and then send a test message:

OPENCLAW_LOG_LEVEL=debug openclaw gateway run

Docs:

wicked briar Mar 4, 2026, 3:29 AM

#

🦞 OpenClaw 2026.3.2 (85377a2) — Built by lobsters, for humans. Don't question the hierarchy.

│
◇
Gateway reachable.

Telegram default: enabled, configured, running, mode:polling, token:config, groups:unmentioned
Telegram agent2: enabled, configured, running, mode:polling, token:config, groups:unmentioned
Telegram agent3: enabled, configured, running, mode:polling, token:config, groups:unmentioned

Warnings:

telegram default: Config allows unmentioned group messages (requireMention=false). Telegram Bot API privacy mode will block most group messages unless disabled. (In BotFather run /setprivacy → Disable for this bot (then restart the gateway).)
telegram agent2: Config allows unmentioned group messages (requireMention=false). Telegram Bot API privacy mode will block most group messages unless disabled. (In BotFather run /setprivacy → Disable for this bot (then restart the gateway).)
telegram agent3: Config allows unmentioned group messages (requireMention=false). Telegram Bot API privacy mode will block most group messages unless disabled. (In BotFather run /setprivacy → Disable for this bot (then restart the gateway).)
Run: openclaw doctor

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

mild harborBOT Mar 4, 2026, 3:30 AM

#

That channels status output explains it: your Telegram bots are running, but Telegram is very likely not delivering group messages to the bot at all because Bot API privacy mode is still enabled.

When privacy mode is ON (default), bots typically won’t see normal group messages, so there’s nothing to show in openclaw logs --follow.

Quick ways to prove it

Mention the bot in the group (or send a /command like /start) and watch logs:

openclaw channels logs --channel telegram
# or
openclaw logs --follow

If mention/commands show up, but normal messages don’t → it’s definitely privacy mode.

Fix (to receive unmentioned group messages)

For each bot you added to the group (default/agent2/agent3 are separate Telegram bot tokens):

#

In BotFather:

/setprivacy
pick your bot
choose Disable

Remove the bot from the group and add it again (Telegram requires this for the privacy change to take effect)
Restart the gateway:

openclaw gateway restart

Then send a normal group message again and check:

openclaw channels logs --channel telegram

#

Docs: https://docs.openclaw.ai/channels/telegram (see the “privacy mode” troubleshooting section)

wicked briar Mar 4, 2026, 3:38 AM

#

Bot's reply: You are not authorized to use this command.

mild harborBOT Mar 4, 2026, 3:39 AM

#

That’s actually a good sign: it means Telegram is reaching your bot, but your Telegram user isn’t authorized (allowlist/pairing rules), so OpenClaw blocks slash-commands.

1) Grab your Telegram numeric user id (`from.id`)

Right after you trigger the command in Telegram, run on the gateway:

openclaw channels logs --channel telegram --lines 200 --json

Look for from.id (your user id) and chat.id (the group id).

2) Allow yourself (DM + group)

In your openclaw.json, add your numeric id to the allowlists (pick the scope you need):

DM authorization: channels.telegram.allowFrom
Group authorization: channels.telegram.groupAllowFrom (or per-group channels.telegram.groups["<chatId>"].allowFrom)

#

Example (JSON5-ish):

{
  channels: {
    telegram: {
      allowFrom: ["tg:123456789"],
      groupAllowFrom: ["tg:123456789"],
    },
  },
}

Then restart:

#

openclaw gateway restart

3) If you still want unmentioned group messages

Keep the BotFather privacy fix from earlier (/setprivacy → Disable, then remove + re-add bot). Otherwise Telegram won’t deliver most normal group messages, regardless of OpenClaw config.

Relevant doc section: https://docs.openclaw.ai/channels/telegram (Access control + Troubleshooting)

wicked briar Mar 4, 2026, 3:50 AM

#

dmPolicy: "pairing",
allowFrom: ["tg:6019338XXXX"],
groupPolicy: "allowlist",
groupAllowFrom: ["tg:6019338XXXX"],

But still got You are not authorized to use this command.

mild harborBOT Mar 4, 2026, 3:52 AM

#

Two big gotchas here:

1) `dmPolicy: "pairing"` means DMs will still be blocked until you pair

In pairing mode, allowFrom does not “auto-authorize” you for DM commands. You must complete pairing (or switch dmPolicy to allowlist).

Pairing flow (DM):

In Telegram DM the bot: /start (it should give you a pairing code)
On the gateway:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

After that, DM commands should work.

If you don’t want pairing, change to:

dmPolicy: "allowlist" + allowFrom: ["tg:<yourNumericId>"]

#

(or dmPolicy: "open" + allowFrom: ["*"])

2) Your `allowFrom` / `groupAllowFrom` entries must be fully numeric

In Telegram config, non-numeric entries are ignored at auth time. So if you literally put something like tg:6019338XXXX in the config, that will be treated as “not authorized”.

Make sure it’s the real ID, e.g.:

allowFrom: ["tg:60193381234"],
groupAllowFrom: ["tg:60193381234"],

3) You have multiple Telegram accounts (default/agent2/agent3)

You might be chatting with the agent2 bot, but only updating the default bot’s allowlist (or vice‑versa).

Quick check: paste the output of

#

openclaw config get channels.telegram

(or at least the channels.telegram.accounts section), and tell me whether the “not authorized” happens in DM or in a group and which bot/account you’re talking to.

wicked briar Mar 4, 2026, 3:55 AM

#

{
"enabled": true,
"dmPolicy": "pairing",
"groups": {
"-1003808241234": {
"requireMention": true,
"groupPolicy": "open"
},
"-1003853751234": {
"requireMention": true,
"groupPolicy": "open"
},
"-1003670911122": {
"requireMention": false,
"groupPolicy": "open"
},
"-100367091111": {
"requireMention": true,
"groupPolicy": "open"
}
},
"allowFrom": [
"tg:60193381111"
],
"groupAllowFrom": [
"tg:60193381111"
],
"groupPolicy": "allowlist",
"streaming": "off",
"network": {
"autoSelectFamily": false,
"dnsResultOrder": "ipv4first"
},
"accounts": {
"default": {
"dmPolicy": "pairing",
"botToken": "OPENCLAW_REDACTED",
"groupPolicy": "allowlist",
"streaming": "partial"
},
"durian": {
"dmPolicy": "pairing",
"botToken": "OPENCLAW_REDACTED",
"groupPolicy": "allowlist",
"streaming": "partial"
},
"durianpro": {
"dmPolicy": "pairing",
"botToken": "OPENCLAW_REDACTED",
"groupPolicy": "allowlist",
"streaming": "partial"
}
}
}

mild harborBOT Mar 4, 2026, 3:56 AM

#

Looking at that config, the important detail is: dmPolicy is still pairing for all 3 Telegram accounts (default, durian, durianpro).

So if you’re testing in a DM, you will still get “You are not authorized…” until you pair + approve (even if allowFrom is set). allowFrom helps when dmPolicy: "allowlist" (or open), but in pairing mode the gate is the pairing store.

Fix (DM case): approve pairing for the right account

In Telegram DM with the bot, send: /start (it should give a pairing code)
On the gateway, approve it for the same bot account you DM’d:

openclaw pairing list telegram --account default
openclaw pairing list telegram --account durian
openclaw pairing list telegram --account durianpro

openclaw pairing approve telegram <CODE> --account <the_one_you_dm'd>

If you’re testing in a group instead

#

Then the most likely issue is simply that the from.id you allowlisted (60193381111) is not the Telegram account you’re currently sending from.

Run right after you trigger the command:

openclaw channels logs --channel telegram --lines 200 --json

and confirm the actual from.id in the inbound update matches what you put in groupAllowFrom.

Tell me: are you seeing the error in DM or in a group, and which bot (default/durian/durianpro) are you messaging?

wicked briar Mar 4, 2026, 3:57 AM

#

DM all working, problem only in group

mild harborBOT Mar 4, 2026, 3:57 AM

#

If DM works but group doesn’t, 99% of the time it’s one of these:

A) The group you’re testing in is not actually allowlisted

Because you have channels.telegram.groups set (with specific -100… keys), Telegram groups become an allowlist. Any group not in that map gets blocked (unless you add "*").

Do this to confirm the real chat.id:

In the group, send a message that the bot will definitely receive (privacy-safe), e.g.

mention the bot: @YourBot ping
or a command: /start@YourBot or /status@YourBot

Immediately on the gateway run:

openclaw channels logs --channel telegram --lines 200 --json

Find the inbound update and check chat.id.
Make sure that exact chat.id exists as a key under channels.telegram.groups.

#

B) You’re sending as an anonymous admin / sender_chat

In some groups, messages can arrive with sender_chat (posted “as the group/channel”), not your user from.id. That will fail your groupAllowFrom check.

Quick test: send a normal message from your personal account (not anonymously) and try again.

If you paste one log entry from openclaw channels logs --channel telegram --json for a group message attempt (redact text if you want), I can tell you immediately whether it’s (A) wrong chat.id, (B) sender_chat/anonymous, or something else.

wicked briar Mar 4, 2026, 4:04 AM

#

I still get "You are not authorized to use this command." even after I added another number to the allowlist

mild harborBOT Mar 4, 2026, 4:05 AM

#

A couple things can make this look like “allowlist doesn’t work” even when you add more numbers:

allowFrom / groupAllowFrom must be the Telegram numeric from.id — not a phone number.
If you added “another number” and it was a phone/contact number, OpenClaw will still treat you as unauthorized.
Restart required. After changing allowlists, do:

openclaw gateway restart

In groups, your message might be coming through as anonymous admin / sender_chat (posted “as the group/channel”), which won’t match your from.id allowlist. Quick test: post from your normal user (not anonymously) and try the command again.

The fastest way to end the guessing

Right after you trigger the command in the group, run:

#

openclaw channels logs --channel telegram --lines 200 --json

and paste the single inbound log object that corresponds to your attempt (you can redact the message text). We need to see what OpenClaw is actually receiving for chat.id and from.id (or whether it’s sender_chat). That will tell us exactly why auth is failing.

wicked briar Mar 4, 2026, 4:21 AM

#

Now I understand, prior to latest release, the bot can reply based on mobile number in Telegram, now it requires Telegram Id
All good

mild harborBOT Mar 4, 2026, 4:22 AM

#

Nice — yep, Telegram allowlists are based on the numeric Telegram user id (from.id), not phone numbers.

If this thread is resolved, please right-click the solution message → Apps → Mark Solution so Answer Overflow can index it for the next person.

wicked briar Mar 4, 2026, 4:23 AM

#

But now I have another problem, without putting allowlist from.id, how to allow all users to be able to use mcporter ? Previously it just used groupPolicy: "open"

mild harborBOT Mar 4, 2026, 4:25 AM

#

If you want everyone in a Telegram group to be able to trigger the bot / run skill commands (like mcporter) without adding each user’s from.id, you need to make sure you’re not in allowlist sender mode for groups.

In practice:

Option 1 (recommended for your case): make groups “open”, remove sender allowlists

In channels.telegram, set group policy to open and remove groupAllowFrom (and any per-group allowFrom overrides):

{
  channels: {
    telegram: {
      dmPolicy: "pairing",   // keep DMs protected if you want
      groupPolicy: "open",   // allow all senders in groups
      // groupAllowFrom: [...]  <-- remove this
      groups: {
        "-1003670911122": { requireMention: true, groupPolicy: "open" },

#

        // or use "*": { requireMention: true, groupPolicy: "open" } for defaults
      },
    },
  },
}

Then:

openclaw gateway restart

Important safety note

Making group chat “open” means anyone in that group can drive the assistant and its tools (and mcporter is a powerful one). Only do this in groups you fully trust; keep requireMention: true at minimum.

If you share the exact group you want opened (the -100... chat id) and whether you want it open for just that group or all groups, I can give you the cleanest config shape (using explicit IDs vs "*").

wicked briar Mar 4, 2026, 4:27 AM

#

How to fix this error:
04:20:31 error [tools] exec failed: exec host not allowed (requested gateway; configure tools.exec.host=sandbox to allow).
04:20:31 error [tools] exec failed: exec host not allowed (requested gateway; configure tools.exec.host=sandbox to allow).

mild harborBOT Mar 4, 2026, 4:28 AM

#

That error means: the agent tried to run exec on the gateway host (host=gateway), but your current policy only allows exec in the sandbox.

Quick fix (make exec run in sandbox)

Set the default exec host back to sandbox and restart:

openclaw config set tools.exec.host '"sandbox"'
openclaw gateway restart

You can also do it just for the current chat session:

/exec host=sandbox

If that then fails because sandboxing/Docker is off

#

host=sandbox only works when the session is actually sandboxed. Check:

openclaw sandbox explain

If you don’t want sandboxing at all, set:

openclaw config set agents.defaults.sandbox.mode '"off"'
openclaw gateway restart

If you intentionally want exec on the gateway host

That’s the “elevated/host exec” path (more risky, especially in open groups). See:

#

If you paste openclaw sandbox explain output (redact anything sensitive), I can tell you which exact knob is blocking it in your setup.

wicked briar Mar 4, 2026, 4:39 AM

#

To enable mcporter in particular group, this is correct right?
"skills": "mcporter" (in openclaw.json)

mild harborBOT Mar 4, 2026, 4:40 AM

#

Almost — the idea is right, but the shape is usually a list, not a single string.

For Telegram group skill filtering:

omit skills → all skills allowed (default)
skills: [] → no skills allowed
skills: ["mcporter"] → only allow mcporter in that group

Example:

{
  channels: {
    telegram: {
      groups: {
        "-1003670911122": {

#

          groupPolicy: "open",
          requireMention: true,
          skills: ["mcporter"],
        },
      },
    },
  },
}

Also: this only filters skills per group — it doesn’t install/enable mcporter by itself. Make sure the mcporter skill is enabled/installed in your Skills settings (or whatever mechanism you’re using to enable skills).

wicked briar Mar 4, 2026, 4:42 AM

#

This Telegram group is missing mcporter/exec permissions. To enable catalog lookups, the group admin needs to add skills: ["mcporter"] and allow group:runtime for this group, or disable sandbox for non-main sessions.

mild harborBOT Mar 4, 2026, 4:44 AM

#

Yep, that message is basically telling you: the group session is sandboxed, and inside sandbox your current sandbox tool policy does not allow runtime tools (exec/process), which mcporter needs.

To fix it you need both:

1) Allow the skill in that group

In the group config (you already found this), use a list:

channels: {
  telegram: {
    groups: {
      "-1003670911122": {
        skills: ["mcporter"],
      },
    },
  },

#

2) Allow `exec` for sandboxed sessions (recommended: do it via a dedicated agent)

If your agents.defaults.sandbox.mode is "non-main", then Telegram groups = sandbox. So you must allow runtime tools in the sandbox tool policy.

Safer approach (only this group gets exec)

Create a dedicated agent (e.g. mcporter) with the sandbox tool allowlist including group:runtime, then bind just that Telegram group to it:

agents: {
  list: [
    { id: "mcporter", /* … */ },
  ],
},

#

bindings: [
  { match: { channel: "telegram", peer: { kind: "group", id: "-1003670911122" } }, agentId: "mcporter" },
],
agents: {
  list: [
    {
      id: "mcporter",
      tools: {
        sandbox: { tools: { allow: ["group:runtime", "group:fs", "group:memory", "group:sessions"] } },
      },
    },
  ],
},

(Exact allow list depends on what else you want working in that sandboxed group; mcporter typically needs at least exec/process.)

#

Fast “global” approach (all sandboxed groups get exec — risky)

Add group:runtime to tools.sandbox.tools.allow globally. Only do this if you really trust all groups.

If you run this and paste the output:

openclaw sandbox explain --session agent:main:telegram:group:-1003670911122

it will tell us exactly which layer is blocking (tools.allow/deny vs tools.sandbox.tools.allow/deny), and I can give you the minimal config change without accidentally locking out other tools. Docs: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

wicked briar Mar 4, 2026, 4:51 AM

#

Effective sandbox:
agentId: main
sessionKey: agent:main:telegram:group:-1003853751111
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: session perSession: true
workspaceAccess: none workspaceRoot: /home/username/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage

Elevated:
enabled: true
channel: (unknown)
allowedByConfig: false

Fix-it:

tools.sandbox.tools.allow
tools.sandbox.tools.deny
agents.list[].tools.sandbox.tools.allow
agents.list[].tools.sandbox.tools.deny
tools.elevated.enabled

mild harborBOT Mar 4, 2026, 4:53 AM

#

That sandbox explain output is super helpful.

What it says (key bits)

Sandbox mode for this group session is currently off (runtime: direct, mode: off), so you’re not actually running inside a Docker sandbox right now.
Sandbox tool policy already allows exec + process (so “allow group:runtime” is effectively already satisfied).
Elevated is blocked: allowedByConfig: false
So anything that tries to run exec on the gateway host via elevated/host mode will be refused.

What to do (pick one)

Option A (safer; recommended for groups): run exec in sandbox, not on the gateway host

Make sure group sessions are sandboxed (common setup):

openclaw config set agents.defaults.sandbox.mode '"non-main"'

Make sure exec defaults to sandbox:

#

openclaw config set tools.exec.host '"sandbox"'
openclaw gateway restart

Then in that Telegram group session, ensure you’re not forcing host exec:

/elevated off
/exec host=sandbox

Option B (host exec from that group session): allow Elevated for Telegram (risky in open groups)

Add your Telegram from.id to the elevated allowlist:

#

  tools: {
    elevated: {
      enabled: true,
      allowFrom: {
        telegram: ["tg:60193381111"]
      }
    }
  }
}

Restart the gateway, then in the group (mention the bot) set:

/elevated on

#

If you tell me which behavior you want for mcporter in that group:

(A) sandboxed exec, or
(B) host/gateway exec,

…I can give you the minimal config diff for your exact setup (especially since you’re also working with “open” group access).

wicked briar Mar 4, 2026, 4:56 AM

#

A

mild harborBOT Mar 4, 2026, 4:57 AM

#

Cool — for A (sandboxed exec) the goal is:

Telegram group sessions run in Docker (so exec happens in the sandbox, not on the gateway host)
exec defaults to host=sandbox
the group allows the mcporter skill

1) Turn on sandboxing for non-main sessions (groups)

This keeps DMs “normal”, but sandboxes group sessions:

openclaw config set agents.defaults.sandbox.mode '"non-main"'

(Requires Docker running. If Docker isn’t installed/running, openclaw doctor will tell you.)

2) Make exec run in the sandbox by default

#

openclaw config set tools.exec.host '"sandbox"'

3) Allow mcporter in that Telegram group

channels: {
  telegram: {
    groups: {
      "-1003853751111": {
        skills: ["mcporter"],
        // (and your existing groupPolicy/requireMention settings)
      }
    }
  }
}

#

4) Restart (and optionally recreate sandboxes)

openclaw gateway restart
openclaw sandbox recreate --agent main

5) Verify

Run again for the group session key:

openclaw sandbox explain --session agent:main:telegram:group:-1003853751111

You want to see sandbox mode non-main (not off), and exec host defaulting to sandbox (and no elevated/host exec involved).

wicked briar Mar 4, 2026, 5:00 AM

#

Effective sandbox:
agentId: main
sessionKey: agent:main:telegram:group:-1003853751111
mainSessionKey: agent:main:main
runtime: sandboxed
mode: non-main scope: session perSession: true
workspaceAccess: none workspaceRoot: /home/username/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage

Elevated:
enabled: true
channel: (unknown)
allowedByConfig: false

Hint: sandbox mode is non-main; use main session key to run direct: agent:main:main

Fix-it:

agents.defaults.sandbox.mode=off
agents.list[].sandbox.mode=off
tools.sandbox.tools.allow
tools.sandbox.tools.deny
agents.list[].tools.sandbox.tools.allow
agents.list[].tools.sandbox.tools.deny
tools.elevated.enabled

mild harborBOT Mar 4, 2026, 5:00 AM

#

That output looks correct for Option A now:

runtime: sandboxed
mode: non-main → Telegram groups are sandboxed, DMs stay direct
sandbox tool policy allows exec + process → this satisfies “allow group:runtime”

So the “mcporter/exec permissions” part should be resolved.

Two quick notes:

1) Elevated is still blocked (but that’s fine)

allowedByConfig: false only matters if something tries to run host exec (e.g. /elevated on/full). For sandboxed group usage, you generally want elevated off anyway.

If you want to stop seeing elevated-related friction entirely, you can disable it:

#

openclaw config set tools.elevated.enabled false
openclaw gateway restart

2) If mcporter still errors, it’s likely a “binary not present in sandbox” / workspace access issue

With workspaceAccess: none, OpenClaw mirrors skills, but if mcporter needs extra files/binaries, you may need:

agents.defaults.sandbox.workspaceAccess: "ro" (safer) or "rw" (more powerful), or
a sandbox setupCommand to install dependencies inside the container.

Try mcporter once in the group now and paste the exact error if it still complains—then we can pick the minimal next knob.

wicked briar Mar 4, 2026, 5:06 AM

#

Still unable to access, I believe previously, it was set to workspace-agent3

mild harborBOT Mar 4, 2026, 5:07 AM

#

Yep — your sandbox explain shows the session key is:

agent:main:telegram:group:-1003853751111

So that Telegram group is currently routed to the main agent/workspace. If mcporter (or its config/files) only exists in your old workspace-agent3, the group won’t see it unless you either:

Option 1 (recommended): route this group to `agent3`

Add a peer binding so that specific Telegram group goes to agent3:

{
  bindings: [
    {
      agentId: "agent3",
      match: {
        channel: "telegram",

#

        peer: { kind: "group", id: "-1003853751111" },
        // accountId: "default" // add this if the group is using a non-default telegram account
      },
    },
  ],
}

Bindings hot-apply; usually no restart needed. After this, the session key will become:

agent:agent3:telegram:group:-1003853751111

Option 2: install/enable `mcporter` in the `main` workspace

If you prefer to keep the group on main, you’ll need to enable/install the mcporter skill in the main agent’s workspace too.

If you’re not sure which Telegram accountId that group is coming in on (default vs durian vs durianpro), run:

#

openclaw channels logs --channel telegram --lines 50 --json

right after a group message and look for accountId, then put that in the binding.

wicked briar Mar 4, 2026, 5:14 AM

#

Revert back to not using sandbox first at this moment, will try again using sandbox later, need more time to read new configuration documentation for this latest release

mild harborBOT Mar 4, 2026, 5:14 AM

#

To turn sandboxing off again (so everything runs direct/on-host):

openclaw config set agents.defaults.sandbox.mode '"off"'

If you only want to disable it for one agent:

openclaw config set agents.list[0].sandbox.mode '"off"'   # adjust index to the right agent

Then re-check:

openclaw sandbox explain --session agent:main:telegram:group:-1003853751111

#

You should see runtime: direct and mode: off.

Docs for later when you’re ready: https://docs.openclaw.ai/gateway/sandboxing

wicked briar Mar 4, 2026, 5:18 AM

#

I have this binding config, but all binding sessions still go to main agent

"bindings": [
{
"agentId": "durian",
"match": {
"channel": "telegram",
"peer": {
"kind": "group",
"id": "-1003853751409"
}
}
},
{
"agentId": "durianpro",
"match": {
"channel": "telegram",
"peer": {
"kind": "group",
"id": "-1003670980625"
}
}
},
{
"agentId": "main",
"match": {
"channel": "telegram",
"accountId": "default"
}
},

mild harborBOT Mar 4, 2026, 5:19 AM

#

A few things can make those bindings look “ignored” even when the JSON is valid:

1) Make sure `agentId: "durian"` / `"durianpro"` actually exist as agents

If there is no agent with that id in agents.list, the binding can’t route to it and you’ll fall back to main.

Check:

openclaw agents list

2) Your `peer.id` must match the exact Telegram `chat.id`

Earlier you showed sessions like ...group:-1003853751111, but your binding example uses -1003853751409. If the id is off by even 1 digit, it won’t match and will fall through to:

{ "agentId": "main", "match": { "channel": "telegram", "accountId": "default" } }

#

Confirm the real chat.id from logs:

openclaw channels logs --channel telegram --lines 200 --json

3) Multi-account gotcha: omit `accountId` = default account only

Per the routing rules, match.accountId omitted means “default account”. If that group message is coming in via the durian / durianpro Telegram account, the peer binding won’t match unless you add the right accountId (or *).

Safer peer binding when you’re not sure which account is used:

{
  agentId: "durian",
  match: {
    channel: "telegram",

#

    accountId: "*",
    peer: { kind: "group", id: "-1003853751409" },
  },
}

4) Expected behavior: routing change creates a new session key

Once it matches, the session key will change from agent:main:telegram:group:... to agent:durian:telegram:group:... (new context).

If you paste:

openclaw agents list output, and
one log entry showing the inbound chat.id + accountId

…I can tell you exactly which of the 3 issues above is happening.

wicked briar Mar 4, 2026, 5:21 AM

#

Agents:

main (default)
Identity: 🍈 PaduAi (IDENTITY.md)
Workspace: ~/.openclaw/workspace
Agent dir: ~/.openclaw/agents/main/agent
Model: ollama/qwen3:14b-q4_K_M
Routing rules: 1
Routing: default (no explicit rules)
durian
Identity: 🍈 MrDurian (IDENTITY.md)
Workspace: ~/.openclaw/workspace-durian
Agent dir: ~/.openclaw/agents/durian/agent
Model: ollama/qwen3:14b-q4_K_M
Routing rules: 2
durianpro
Identity: 🍈 MrDurianPro (IDENTITY.md)
Workspace: ~/.openclaw/workspace-durianpro
Agent dir: ~/.openclaw/agents/durianpro/agent
Model: ollama/qwen3:14b-q4_K_M
Routing rules: 2

mild harborBOT Mar 4, 2026, 5:21 AM

#

Nice — agents exist, so it’s not “unknown agent id”.

At this point it’s almost certainly one of these two:

1) The group id in the binding doesn’t match the real `chat.id`

In this thread you’ve shown different group ids (e.g. your sandbox explain earlier had ...group:-1003853751111, but your binding example uses -1003853751409).

If the id is off by even one digit, the peer binding won’t match and it will fall through to your main catch-all:

{ agentId: "main", match: { channel: "telegram", accountId: "default" } }

2) AccountId mismatch (multi-account Telegram)

If the message comes in on accountId: durian / durianpro, but the binding omits accountId, it may not match (omit = default). Easiest is to set accountId: "*" on the peer bindings.

#

Next step (fastest to verify)

Send one message in the problem group, then immediately run:

openclaw channels logs --channel telegram --lines 80 --json

Paste the single inbound log object that includes:

chat.id
accountId

With those two fields I can tell you exactly which binding should match (and what to change). If you prefer, you can also paste:

openclaw agents bindings --json

#

so we can confirm the gateway is seeing the peer bindings you expect.

wicked briar Mar 4, 2026, 5:26 AM

#

There's no inbound message from openclaw channels logs --channel telegram --lines 80 --json

mild harborBOT Mar 4, 2026, 5:27 AM

#

That can be normal: openclaw channels logs --channel telegram doesn’t guarantee you’ll see inbound message events. It’s basically a filtered slice of the gateway log file, and inbound Telegram updates are often only logged when you turn on extra verbosity/diagnostics.

Best quick check: tail full logs while sending a message

In one terminal:

openclaw logs --follow

Then send a message in the Telegram group (ideally mention the bot, so Telegram definitely delivers it).

If you still don’t see anything Telegram-related in openclaw logs --follow, then your current log level/flags probably aren’t emitting inbound update details.

Enable Telegram debug diagnostics (targeted, better than “debug everything”)

Add this to openclaw.json:

#

{
  diagnostics: {
    enabled: true,
    flags: ["telegram.payload", "telegram.http"]
  }
}

Then try again with:

openclaw logs --follow

(You can remove those flags afterward.)

#

Fallback to get the group id without relying on OpenClaw logs

Use Telegram’s official Bot API getUpdates for the bot that’s in the group and read message.chat.id (that’s the -100… id you need for bindings). This is often the fastest when logs are quiet.

If you paste the output of openclaw logs --follow right after you send a group message (even if it looks irrelevant), I can tell you whether Telegram updates are being logged at all and what knob to turn next.

wicked briar Mar 4, 2026, 5:31 AM

#

Only this came out from openclaw logs --follow

05:30:19 warn compaction-safeguard {"subsystem":"compaction-safeguard"} Compaction safeguard: cancelling compaction with no real conversation messages to summarize.
05:30:38 warn compaction-safeguard {"subsystem":"compaction-safeguard"} Compaction safeguard: cancelling compaction with no real conversation messages to summarize.
05:30:38 warn compaction-safeguard {"subsystem":"compaction-safeguard"} Compaction safeguard: cancelling compaction with no real conversation messages to summarize.
05:30:53 debug cron {"module":"cron","storePath":"/home/manjohari/.openclaw/cron/jobs.json"} {"nextAt":1772604000000,"delayMs":60000,"clamped":true} cron: timer armed
05:30:57 warn compaction-safeguard {"subsystem":"compaction-safeguard"} Compaction safeguard: cancelling compaction with no real conversation messages to summarize.

mild harborBOT Mar 4, 2026, 5:32 AM

#

Those lines confirm you’re tailing the right log file (gateway is logging), but it also means: your gateway isn’t seeing any Telegram traffic at all (no gateway/channels/telegram / polling / update handling logs).

That usually comes down to one of these:

1) The messages aren’t reaching this gateway

You’re messaging a different Telegram bot than the one configured here (easy with multiple accounts/tokens), or
Another process is consuming updates (polling mode): only one poller can “own” a bot token at a time.

2) Telegram isn’t emitting inbound logs at your current settings

Let’s force high-signal Telegram logging:

Add to openclaw.json:

{
  diagnostics: {
    enabled: true,

#

    flags: ["telegram.*"]
  }
}

Then:

openclaw logs --follow

…and send /start in DM to the bot and a mentioned message in the group.

3) Get a quick health view of Telegram runtime

Paste this output:

#

openclaw channels status --probe
openclaw channels logs --channel telegram

With that, we can tell if:

the poller is actually running,
you’re hitting a token/update conflict,
or you’re just talking to a different bot/account than the gateway config.

wicked briar Mar 4, 2026, 5:36 AM

#

Gateway reachable.

Telegram default: enabled, configured, running, mode:polling, bot:@paduaimy_bot, token:config, works
Telegram durian: enabled, configured, running, in:just now, mode:polling, bot:@mrdurian_ai_bot, token:config, works
Telegram durianpro: enabled, configured, running, mode:polling, bot:@durian_ai_bot, token:config, works

2026-03-04T13:33:22.916+08:00 info {"subsystem":"gateway/channels/telegram"} [durianpro] starting provider (@durian_ai_bot)
2026-03-04T13:33:22.918+08:00 info {"subsystem":"gateway/channels/telegram"} [durian] starting provider (@mrdurian_ai_bot)

#

The bot did send reply from mentioned question in the group

mild harborBOT Mar 4, 2026, 5:37 AM

#

Good — that output confirms the Telegram providers are actually running and healthy (works, bots start, polling).

The reason you still don’t see “incoming messages” in openclaw logs --follow is simply: OpenClaw doesn’t log every inbound Telegram update at info level by default (too noisy + contains PII). So you’ll mostly see startup/health lines unless you turn on targeted diagnostics.

Turn on Telegram inbound logging (recommended)

Add this to openclaw.json (or set via openclaw config set):

{
  diagnostics: {
    enabled: true,
    flags: ["telegram.payload"]
  }
}

Then:

#

openclaw logs --follow

Now send a message in the Telegram group (mention the bot). You should start seeing log entries that include the inbound payload with chat.id, from.id, and which account handled it (default / durian / durianpro).

When you’re done debugging, remove telegram.payload again (it will log a lot of personal data).

Note on `openclaw channels logs --channel telegram`

That command is mainly for channel/runtime logs (startup, errors), not a full “message inbox”. For message-level tracing, diagnostics flags are the right tool.

#

Good — that confirms the bot is receiving the group message (at least when mentioned) and replying correctly.

So the remaining gap is just visibility in logs, not delivery.

If you still want to see the inbound group message details (including chat.id, from.id, and which Telegram accountId handled it), enable:

diagnostics: { enabled: true, flags: ["telegram.payload"] }

then run:

openclaw logs --follow

Send one more mentioned message, and you should get the payload lines you can use for bindings/debugging.

wicked briar Mar 4, 2026, 6:03 AM

#

I still didn't get any inbound or outbound message, running on Ubuntu 25.10

mild harborBOT Mar 4, 2026, 6:03 AM

#

Do you mean:

No inbound/outbound in the logs (but the bot still replies in Telegram), or
The bot doesn’t reply in Telegram either?

They point to different problems.

If the bot replies, but logs show nothing

Most likely your Telegram diagnostics are emitting debug-level logs but your file log level is too high. On Ubuntu, set these (temporarily) and retry:

openclaw config set logging.level '"debug"'
openclaw config set diagnostics.enabled true
openclaw config set diagnostics.flags '["telegram.payload"]'

Then:

#

openclaw logs --follow

Send a mentioned message in the group again.

If openclaw logs --follow still shows nothing, tail the log file directly on the gateway host:

tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

If the bot does NOT reply in Telegram

Paste these outputs (they’re the fastest signal):

#

openclaw gateway status
openclaw channels status --probe

Also: in polling mode, make sure no other machine/process is running getUpdates for the same bot token (only one poller can receive updates).

wicked briar Mar 4, 2026, 6:11 AM

#

Only this for Inbound message

{"0":"{"subsystem":"compaction-safeguard"}","1":"Compaction safeguard: cancelling compaction with no real conversation messages to summarize.","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"compaction-safeguard"}","parentNames":["openclaw"],"date":"2026-03-04T06:10:20.126Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/manjohari/.npm-global/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427:14","fileName":"subsystem-BfkFJ4uQ.js","fileNameWithLine":"subsystem-BfkFJ4uQ.js:427","fileColumn":"14","fileLine":"427","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427","method":"logToFile"}},"time":"2026-03-04T14:10:20.127+08:00"}

mild harborBOT Mar 4, 2026, 6:12 AM

#

That JSON blob is the clue: it’s a WARN log entry:

"logLevelName":"WARN"

So your file log level is effectively warn, which means you will not see the Telegram inbound/outbound stuff (those are typically info/debug), even if Telegram is working.

Fix: lower the file log level + enable Telegram payload diagnostics

Run:

openclaw config set logging.level '"debug"'
openclaw config set diagnostics.enabled true
openclaw config set diagnostics.flags '["telegram.payload","telegram.http"]'
openclaw gateway restart

Then:

#

openclaw logs --follow

Send a mentioned message in the group again — you should start seeing Telegram entries (including chat.id, from.id, accountId).

If it still only shows WARN after that

Double-check you’re editing the same config file the gateway service is using:

openclaw config file
openclaw gateway status

(That “Config (cli)” vs “Config (service)” mismatch is a very common reason changes don’t affect logs.)

wicked briar Mar 4, 2026, 6:17 AM

#

Now it appears in the log 🙂 bravo.
Let's go back with mcporter problem, on host, disable sandbox, agent bindings

06:15:38 debug gateway/channels/telegram/raw-update {"subsystem":"gateway/channels/telegram/raw-update"} telegram update: {"update_id":75433688,"message":{"message_id":639,"from":{"id":1087968824,"is_bot":true,"first_name":"Group","username":"GroupAnonymousBot"},"sender_chat":{"id":-1003853751409,"title":"Yayasan Durian Chat","username":"yayasandurianchat","type":"supergroup"},"chat":{"id":-1003853751409,"title":"Yayasan Durian Chat","username":"yayasandurianchat","type":"supergroup"},"date":1772604938,"text":"@mrdurian_ai_bot lakukan web search untuk D201","entities":[{"offset":0,"length":16,"type":"mention"}]}}

mild harborBOT Mar 4, 2026, 6:18 AM

#

Nice — that raw-update line explains a lot:

from.id is 1087968824 and username is GroupAnonymousBot
and there’s a sender_chat field

That means the message was sent in the group as an anonymous admin / sender_chat post, so Telegram does not expose the real user id. Any allowlist checks will see the sender as GroupAnonymousBot, not your actual account.

Now, for what you asked: host exec (no sandbox) + route this group to the right agent.

1) Disable sandbox (host mode)

openclaw config set agents.defaults.sandbox.mode '"off"'

2) Make `exec` run on the host (gateway)

When sandbox is off, don’t leave exec “sandbox-defaulted”:

#

openclaw config set tools.exec.host '"gateway"'

(You may also need to adjust tools.exec.security/ask depending on your approvals setup.)

3) Fix the binding for that group (peer + accountId)

From your log, the group chat id is:

chat.id = -1003853751409

and the bot being mentioned is @mrdurian_ai_bot, which matches your Telegram accountId durian.

So your binding should be:

#

{
  bindings: [
    {
      agentId: "durian",
      match: {
        channel: "telegram",
        accountId: "durian",
        peer: { kind: "group", id: "-1003853751409" },
      },
    },
  ],
}

After that, new messages in that group should create sessions under:

#

agent:durian:telegram:group:-1003853751409

4) If you still hit “not authorized” in group

Because the sender is GroupAnonymousBot, either:

keep groupPolicy: "open" for that group (no sender allowlist), or
stop sending as anonymous admin so Telegram includes the real from.id (best if you want per-user auth).

If you paste your current bindings section and your channels.telegram.groups["-1003853751409"] entry, I can sanity-check that nothing else is overriding it.

wicked briar Mar 4, 2026, 6:35 AM

#

06:35:00 debug gateway/channels/telegram/raw-update {"subsystem":"gateway/channels/telegram/raw-update"} telegram update: {"update_id":75433690,"message":{"message_id":641,"from":{"id":7908920886,"is_bot":false,"first_name":"Pulut","last_name":"Cafe","username":"pulutcafe","language_code":"en"},"chat":{"id":-1003853751409,"title":"Yayasan Durian Chat","username":"yayasandurianchat","type":"supergroup"},"date":1772606094,"text":"Hilang?"}}

mild harborBOT Mar 4, 2026, 6:36 AM

#

Perfect — this update is no longer anonymous admin:

real user: from.id = 7908920886 (pulutcafe)
group: chat.id = -1003853751409

So any auth/allowlist logic will now work “normally” (earlier you were seeing GroupAnonymousBot, which breaks user-based allowlists).

What this unlocks

If you want allowlist mode (only some users can run commands/skills)

Add that user id:

channels: {
  telegram: {
    groupPolicy: "allowlist",

#

    groupAllowFrom: ["tg:7908920886"],
  },
}

(or per-group groups["-1003853751409"].allowFrom)

If you want open group (everyone can talk to the bot)

Keep:

channels: {
  telegram: {
    groups: {
      "-1003853751409": { groupPolicy: "open" }

#

    }
  }
}

…but note: slash commands / skill commands are still subject to command authorization rules (see commands.useAccessGroups). If you want everyone in an open group to be able to run /mcporter (and other /... commands), that’s possible, but it’s a security tradeoff.

Agent binding for this group (durian bot → durian agent)

Since the bot being used is @mrdurian_ai_bot (your durian account), the clean binding is:

{
  agentId: "durian",
  match: {
    channel: "telegram",

#

    accountId: "durian",
    peer: { kind: "group", id: "-1003853751409" }
  }
}

If you tell me exactly how you’re invoking mcporter (native /mcporter command vs /skill mcporter ... vs “natural language”), I can point you to the one config knob that controls who’s allowed to run it in groups.

wicked briar Mar 4, 2026, 6:37 AM

#

using natural language with certain keywords like "catalog"

mild harborBOT Mar 4, 2026, 6:38 AM

#

Got it — if you’re not using /mcporter as a command, but relying on normal chat text (e.g. messages containing “catalog”), then command authorization is not the gate.

For natural-language triggering, the gates are basically:

Group message allowed (groupPolicy, groups allowlist, mention rules)
Skill allowed in that group (channels.telegram.groups[<id>].skills)
The skill can actually run its tools (usually exec/process for mcporter)

Minimal config for “anyone in this group can trigger mcporter via normal text”

For your group -1003853751409:

{
  channels: {
    telegram: {
      groups: {

#

        "-1003853751409": {
          groupPolicy: "open",
          requireMention: true,     // optional but recommended in groups
          skills: ["mcporter"],     // allow mcporter in this group
        },
      },
    },
  },
}

Make sure the group is routed to the agent you expect (e.g. durian) so it’s using the workspace where mcporter is enabled/installed:

#

  bindings: [
    {
      agentId: "durian",
      match: {
        channel: "telegram",
        accountId: "durian",
        peer: { kind: "group", id: "-1003853751409" },
      },
    },
  ],
}

Host mode (no sandbox): make sure mcporter can run exec

If you’re running on-host (sandbox off), mcporter will typically need exec/process:

#

openclaw config set agents.defaults.sandbox.mode '"off"'
openclaw config set tools.exec.host '"gateway"'

Strong warning: open group + host exec is dangerous. If you want “anyone can ask catalog questions” but don’t want random users to be able to steer exec broadly, the safer long-term setup is: keep groups sandboxed (sandbox.mode="non-main") and allow exec only inside sandbox.

If you paste the exact mcporter error you get when someone says a “catalog …” message, I can tell which of the 3 gates above is still blocking in your setup.

wicked briar Mar 4, 2026, 11:18 AM

#

The mcporter is working find right now, now no reply when user mentioned

mild harborBOT Mar 4, 2026, 11:19 AM

#

If mcporter is working but the bot “goes silent” when someone mentions it, the fastest way to pinpoint it is to answer one question:

Does the mentioned message even reach the gateway?

1) Grab the `raw-update` log line for a mentioned message

With your current logging (you already have gateway/channels/telegram/raw-update), send one message in the group like:

@mrdurian_ai_bot ping

Then copy/paste the corresponding raw-update JSON line.

What we’re looking for in that update:

chat.id (make sure it’s the group you configured)
from.id (make sure it’s a real user, not GroupAnonymousBot / sender_chat)
entities includes { type: "mention" } (so mention gating should pass)
which bot account handled it ([durian] / default / durianpro prefix in the log)

#

2) Common causes (based on what we see in raw-update)

Still anonymous admin / sender_chat → auth/allowlist may fail or mention rules behave weirdly.
Mention isn’t actually a Telegram @mention (no entities: mention) → requireMention: true won’t trigger.
GroupPolicy/allowlists: if groupPolicy: "allowlist", that user must be in groupAllowFrom (or switch the group to groupPolicy: "open").

Paste that raw-update line and your channels.telegram.groups["-1003853751409"] config block, and I’ll tell you exactly which one it is.

wicked briar Mar 4, 2026, 11:20 AM

#

09:55:37 debug gateway/channels/telegram/raw-update {"subsystem":"gateway/channels/telegram/raw-update"} telegram update: {"update_id":75433715,"message":{"message_id":683,"from":{"id":51235354,"is_bot":false,"first_name":"Yu. Suffi Yusof","last_name":"| www.cikgusuffi.com","username":"Suffi"},"chat":{"id":-1003853751409,"title":"Yayasan Durian Chat","username":"yayasandurianchat","type":"supergroup"},"date":1772618137,"text":"@mrdurian_ai_bot hari ni kat terong hujan dak?","entities":[{"offset":0,"length":16,"type":"mention"}]}}

mild harborBOT Mar 4, 2026, 11:21 AM

#

That raw update looks perfect for mention-gating:

correct group: chat.id = -1003853751409
real user: from.id = 51235354
has entities: [{ type: "mention" }]

So the reason there’s no reply is almost certainly authorization, not “mention not detected”.

In other words: the bot sees the message, but then drops it because that sender isn’t allowed under your current group access rules (very common when groupPolicy: "allowlist" / groupAllowFrom is set to only your id — which would also explain why mcporter “works for you” but not for other users).

Fix options

Option A (allow everyone in that group): set that group to open

openclaw config set channels.telegram.groups[\"-1003853751409\"].groupPolicy '\"open\"'

#

Option B (keep allowlist, add this user):

openclaw config set channels.telegram.groupPolicy '\"allowlist\"'
openclaw config set channels.telegram.groupAllowFrom '[\"tg:51235354\", \"tg:<your-id>\"]'

(You can also put the allowlist per-group via channels.telegram.groups["-100..."].allowFrom if you want it only for that group.)

If you paste your current values for:

openclaw config get channels.telegram.groupPolicy
openclaw config get channels.telegram.groupAllowFrom
openclaw config get channels.telegram.groups["-1003853751409"]

…I’ll tell you exactly which key is currently blocking the sender and what the minimal change is.

wicked briar Mar 4, 2026, 11:25 AM

#

openclaw config get channels.telegram.groupPolicy
allowlist

openclaw config get channels.telegram.groupAllowFrom
[
"tg:4715738",
"7908920886"
]

openclaw config get channels.telegram.groups["-1003853751409"]
{
"requireMention": true,
"groupPolicy": "open",
"skills": [
"mcporter"
]
}

mild harborBOT Mar 4, 2026, 11:27 AM

#

That log line explains why there’s no reply:

Mention message is from from.id = 51235354
But your global allowlist is:

groupAllowFrom = ["tg:4715738", "7908920886"]

So that user isn’t authorized, and OpenClaw will drop the message after receiving it.

Now, you do have a per-group override:

groups["-1003853751409"].groupPolicy = "open"

…but given the behavior, your durian account is still effectively using allowlist rules.

#

Quick fix (open that Telegram account for groups)

Since the message is going to @mrdurian_ai_bot (= accountId durian), set the account-level groupPolicy to open:

openclaw config set channels.telegram.accounts.durian.groupPolicy '"open"'
openclaw gateway restart

After that, anyone in allowed groups (your channels.telegram.groups allowlist) should be able to mention and get a reply.

Alternative (keep allowlist, just add this user)

openclaw config set channels.telegram.groupAllowFrom '[ "tg:4715738", "tg:7908920886", "tg:51235354" ]'
openclaw gateway restart

(Also: I’d add the tg: prefix consistently, just to avoid any normalization edge cases.)

#

If you run one more mention after the change and it’s still silent, paste the next raw-update plus the next ~10 log lines after it — we should then see an explicit “dropped/unauthorized” vs “ran but NO_REPLY”.

wicked briar Mar 4, 2026, 11:42 AM

#

How this works?

"messages": {
"ackReactionScope": "group-mentions"
},

mild harborBOT Mar 4, 2026, 11:42 AM

#

messages.ackReactionScope controls when OpenClaw adds the “I’m working on it” reaction (the emoji from messages.ackReaction / identity emoji fallback) to an incoming message.

With:

messages: {
  ackReactionScope: "group-mentions"
}

it means:

In Telegram/Discord/Slack/etc group chats: add the ack reaction only when the bot was mentioned (i.e. the message that actually triggers the bot in “mention” activation mode).
In DMs: it will not ack-react (unless you set the scope to direct or all).

Other values:

group-all → ack-react for all group messages that trigger processing (can be noisy)

#

direct → only DMs
all → DMs + groups

Notes:

This only does something if an ack emoji is set (explicitly or via fallback). Fallback is usually the agent’s identity.emoji, otherwise "👀".
If you want it to disappear after the bot replies, set:
```
messages: { removeAckAfterReply: true }
```

wicked briar Mar 4, 2026, 11:58 AM

#

This log from admin/owner and no reply

11:57:34 debug gateway/channels/telegram/raw-update {"subsystem":"gateway/channels/telegram/raw-update"} telegram update: {"update_id":75433726,"message":{"message_id":693,"from":{"id":1087968824,"is_bot":true,"first_name":"Group","username":"GroupAnonymousBot"},"sender_chat":{"id":-1003853751409,"title":"Yayasan Durian Chat","username":"yayasandurianchat","type":"supergroup"},"chat":{"id":-1003853751409,"title":"Yayasan Durian Chat","username":"yayasandurianchat","type":"supergroup"},"date":1772625453,"text":"@mrdurian_ai_bot who are you","entities":[{"offset":0,"length":16,"type":"mention"}]}}

mild harborBOT Mar 4, 2026, 11:59 AM

#

That log is an anonymous admin message.

Telegram represents anonymous admin posts as coming from:

from.is_bot: true
from.username: "GroupAnonymousBot"
plus sender_chat: { id: <the group/channel> }

Most bots (including OpenClaw) ignore messages from bots to prevent bot-loops, so it won’t reply — even if you’re the owner/admin — because as far as Telegram is concerned, the sender is literally a bot.

Fix

In that Telegram group:

Open Group Info → Administrators
Tap your admin user
Turn off “Remain Anonymous” (or “Post as the group/channel”)

#

Then send the message again (as your real user). You’ll see a raw-update with from.is_bot: false and your numeric from.id, and OpenClaw will reply normally.

If you need to keep anonymous admin on, the workaround is: use a non-anonymous account to talk to the bot, or DM the bot.

wicked briar Mar 4, 2026, 12:07 PM

#

Still not working, it was working before this when used mobile number

mild harborBOT Mar 4, 2026, 12:08 PM

#

Telegram can’t work “by mobile number” in the way WhatsApp does — Telegram does not expose users’ phone numbers to bots, so OpenClaw can’t authorize/identify you by your mobile number.

Right now your log still shows you’re sending as an anonymous admin:

from.username = "GroupAnonymousBot"
from.is_bot = true
sender_chat is present

OpenClaw will (correctly) ignore that, because it’s a bot sender.

What to do

In the group: Group Info → Administrators → (your admin) → disable “Remain Anonymous”.
Also check the composer: some groups have a “Send as …” selector (you might still be sending “as the group/channel”). Switch it to your personal account.
Verify with logs: send one message mentioning the bot and confirm the raw-update shows:
- from.is_bot: false
- your real numeric from.id

#

If you paste the next raw-update after you try that (the one that should be is_bot:false), we can confirm whether Telegram is still treating you as anonymous or whether something else is blocking replies.

wicked briar Mar 4, 2026, 12:08 PM

#

I removed tg:number from allowList

12:06:55 debug gateway/channels/telegram/raw-update {"subsystem":"gateway/channels/telegram/raw-update"} telegram update: {"update_id":75433729,"message":{"message_id":695,"from":{"id":7908920886,"is_bot":false,"first_name":"Pulut","last_name":"Cafe","username":"pulutcafe","language_code":"en"},"chat":{"id":-1003853751409,"title":"Yayasan Durian Chat","username":"yayasandurianchat","type":"supergroup"},"date":1772626014,"text":"@mrdurian_ai_bot who are you","entities":[{"offset":0,"length":16,"type":"mention"}]}}
12:07:26 debug cron {"module":"cron","storePath":"/home/manjohari/.openclaw/cron/jobs.json"} {"nextAt":1772632800000,"delayMs":60000,"clamped":true} cron: timer armed

mild harborBOT Mar 4, 2026, 12:09 PM

#

That raw-update shows the mention is arriving correctly (real user, has entities: mention, correct chat.id). The reason you’re seeing no reply (and no further logs after raw-update) is almost certainly that the message is getting dropped by the group sender policy before it ever reaches the agent.

And you just said you removed tg:<number> from the allowlist — so if your effective policy is still groupPolicy: "allowlist" for the durian account, then nobody (including you) can trigger runs anymore.

Quick fix (open groups for the `durian` Telegram account)

Set the account-level groupPolicy to open:

openclaw config set channels.telegram.accounts.durian.groupPolicy '"open"'
openclaw gateway restart

Then try the same message again.

Alternative (stay allowlist-based)

Put your id back (and any other users you want to allow):

#

openclaw config set channels.telegram.groupAllowFrom '[ "tg:7908920886", "tg:51235354" ]'
openclaw gateway restart

Why I’m confident it’s policy-drop: if it were reaching the agent, you’d typically see additional “message queued / run started” type logs after the raw-update. Here it stops immediately.

If you paste:

openclaw config get channels.telegram.accounts.durian.groupPolicy
openclaw config get channels.telegram.groupPolicy

I can tell you exactly which one is currently winning in your setup.

wicked briar Mar 4, 2026, 12:11 PM

#

openclaw config get
error: missing required argument 'path'

mild harborBOT Mar 4, 2026, 12:11 PM

#

Yep — config get always needs a path.

Examples you can run:

openclaw config get channels.telegram.groupPolicy
openclaw config get channels.telegram.groupAllowFrom
openclaw config get channels.telegram.accounts.durian.groupPolicy
openclaw config get channels.telegram.groups["-1003853751409"]

If you want to see a bigger chunk, you can also do:

openclaw config get channels.telegram

wicked briar Mar 4, 2026, 12:15 PM

#

open
[
"tg:4715738"
]
open
{
"requireMention": true,
"groupPolicy": "open",
"skills": [
"mcporter"
]
}

mild harborBOT Mar 4, 2026, 12:16 PM

#

Thanks — those outputs mean:

channels.telegram.groupPolicy is now open
channels.telegram.accounts.durian.groupPolicy is open
and for the specific group -1003853751409, groupPolicy is open

So auth/allowlist is no longer the reason other users get no reply (your groupAllowFrom list is basically irrelevant when policy is open).

At this point the most likely reason for “mentioned but no reply” is:

Your group is configured as “mcporter-only”

You have:

skills: ["mcporter"]

#

So the agent will tend to only “wake up meaningfully” when the message looks like a catalog/mcporter request. A mention like “who are you” may just lead to NO_REPLY / no useful action depending on your prompts/model behavior.

If you want the bot to answer normal questions too, change that group config to either:

remove the skills filter (omit it entirely = all skills allowed), or
keep it but add a group systemPrompt that explicitly says “always answer when mentioned; use mcporter only for catalog queries”.

Example:

channels: {
  telegram: {
    groups: {
      "-1003853751409": {
        requireMention: true,
        groupPolicy: "open",
        // skills: ["mcporter"], // remove this if you want normal chat too

#

        systemPrompt: "Reply whenever mentioned. If the user asks about catalog/products, use mcporter; otherwise answer normally.",
      },
    },
  },
}

One quick sanity test: in that group, have a non-allowlisted user mention the bot with a clear catalog prompt (e.g. “@bot catalog D201”). If that works but “who are you” doesn’t, it’s definitely “mcporter-only behavior”, not routing/auth.

wicked briar Mar 4, 2026, 12:25 PM

#

What is this warning for? and how to fix this

12:23:42 warn compaction-safeguard {"subsystem":"compaction-safeguard"} Compaction safeguard: cancelling compaction with no real conversation messages to summarize.

mild harborBOT Mar 4, 2026, 12:27 PM

#

That warning is coming from the compaction safeguard (the default agents.defaults.compaction.mode: "safeguard").

It means OpenClaw tried to run a compaction pass (summarize old chat history), but the session doesn’t contain any “real” conversation turns yet (often it’s only system messages / directives / empty history), so it cancels the compaction instead of producing a useless summary.

Is it bad?

No — it’s harmless. It’s basically “nothing to compact”.

Common causes

You (or a plugin) triggered /compact in a fresh/new session.
A session exists but has no normal user/assistant messages yet (only tooling/system noise).

How to “fix” / silence it

Do nothing (recommended), or
Don’t run /compact until there’s actual conversation, or
If you really want to reduce these warnings, switch compaction mode off safeguard:

#

openclaw config set agents.defaults.compaction.mode '"default"'

Docs: https://docs.openclaw.ai/concepts/compaction

wicked briar Mar 4, 2026, 12:38 PM

#

What's the available options for requireMention

mild harborBOT Mar 4, 2026, 12:38 PM

#

For channels.telegram.groups["<chatId>"].requireMention, the options are just:

true (default) — the bot only “wakes up” in that group when it’s mentioned
- mention can be a real Telegram @botusername mention or a match against your configured mention patterns (agents.list[].groupChat.mentionPatterns / messages.groupChat.mentionPatterns)
false — the bot can respond to unmentioned group messages too

Example:

channels: {
  telegram: {
    groups: {
      "-1003853751409": {
        requireMention: true,  // or false
      },
    },

#

  },
}

Notes for Telegram specifically:

If you set requireMention: false, you usually need to disable Telegram privacy mode (/setprivacy -> Disable in BotFather, then remove + re-add the bot), otherwise Telegram won’t deliver most unmentioned group messages to the bot.
You can also toggle it per-session with /activation mention vs /activation always (session state, not permanent config).

wicked briar Mar 4, 2026, 12:42 PM

#

What's the default value?

mild harborBOT Mar 4, 2026, 12:42 PM

#

Default is requireMention: true for Telegram groups — i.e. the bot only responds when mentioned (unless you override it per-group / with /activation always).

wicked briar Mar 4, 2026, 1:55 PM

#

Explain streaming in Telegram

mild harborBOT Mar 4, 2026, 1:56 PM

#

Telegram streaming in OpenClaw is “live preview while the model is thinking”, implemented using Telegram-native features (drafts + message edits), not by sending lots of separate messages.

The main knob

channels.telegram.streaming:

off → no live preview; only a final message is sent
partial (default) → stream a live preview while generating
progress → alias of partial on Telegram (kept for cross-channel naming)
block → legacy/compat mode; if you explicitly enable “block streaming”, OpenClaw avoids double-streaming (it won’t also do the Telegram preview stream)

How it behaves

DMs (1:1)

Uses Telegram draft streaming (sendMessageDraft) when available.
You see the reply “typing itself” in the draft area, then it sends the final message.

Groups / forum topics

OpenClaw sends a preview message, then keeps updating it via editMessageText.

#

When the model is done, it does one final edit in place (so you don’t get two messages).

Fallbacks

If Telegram rejects HTML/formatting, OpenClaw retries as plain text.
If native draft transport is unavailable/rejected, it falls back to sendMessage + editMessageText.
For complex outputs (media, etc.), it may skip preview streaming and just send the final payload.

Config example

{
  channels: {
    telegram: {
      streaming: "partial", // off | partial | progress | block
    },
  },
}

#

Doc section: https://docs.openclaw.ai/channels/telegram (Live stream preview).

wicked briar Mar 4, 2026, 1:58 PM

#

Give examples for each option

mild harborBOT Mar 4, 2026, 1:58 PM

#

Here are concrete examples for each channels.telegram.streaming option (this is preview streaming, not block replies).

Config key: channels.telegram.streaming (or per account: channels.telegram.accounts.<id>.streaming)

1) `streaming: "off"`

Config:

{
  channels: { telegram: { streaming: "off" } }
}

What you see:

DMs: nothing while the model thinks → then one final message appears.
Groups: same: one final message only.

#

Use this if you hate “live drafts/edits” and only want final answers.

2) `streaming: "partial"` (default)

Config:

{
  channels: { telegram: { streaming: "partial" } }
}

What you see:

DMs: Telegram “draft” updates live (the reply text appears to type/update), then final send.
Groups/topics: OpenClaw sends one preview message and keeps editing it to the latest partial text, then does a final edit.

Use this for a “live typing preview”.

#

3) `streaming: "block"`

Config:

{
  channels: { telegram: { streaming: "block" } }
}

What you see:

DMs: preview updates come in chunked / appended steps (less “rewrite flicker”, more “growing message”).
Groups/topics: same idea: the preview message grows in chunks rather than constantly being replaced with the latest full partial.

Use this if partial feels too “jittery” and you prefer chunk-by-chunk growth.

#

4) `streaming: "progress"`

Config:

{
  channels: { telegram: { streaming: "progress" } }
}

Telegram note: on Telegram, progress currently maps to partial (it’s mostly meaningful on Slack).
So on Telegram you’ll effectively get the same behavior as partial.

Extra: this is separate from “block replies”

If you want the bot to actually send multiple message bubbles as it generates (not just a preview edit), that’s block streaming and is controlled elsewhere (agents.defaults.blockStreamingDefault + channels.telegram.blockStreaming).

wicked briar Mar 4, 2026, 2:02 PM

#

Best scenario to use this block option

mild harborBOT Mar 4, 2026, 2:03 PM

#

Use channels.telegram.streaming: "block" when you want a live preview, but you don’t want the preview text to constantly get rewritten (the “flicker” you can get with partial).

Best scenarios:

Long answers (multi-paragraph / step-by-step) where it’s useful for readers to start reading the first chunk while the rest is still generating.
Slow models / slow runs (local models, tool-heavy workflows) where partial would produce a lot of tiny edits; block tends to update in bigger, more readable chunks.
Busy groups where you want fewer edits and a calmer UX (one message that “grows” in chunks).

Don’t use it if:

You already enable block replies (multi-message chunking) for Telegram — in that case OpenClaw may skip preview streaming to avoid double-streaming.
You want the smoothest “always current” single-preview behavior → that’s partial.

wicked briar Mar 4, 2026, 2:05 PM

#

what's the effect for user experience in Telegram group with 1,000 users

#Telegram: how to check incoming message from group?

Quick ways to prove it

Fix (to receive unmentioned group messages)

1) Grab your Telegram numeric user id (from.id)

2) Allow yourself (DM + group)

3) If you still want unmentioned group messages

1) dmPolicy: "pairing" means DMs will still be blocked until you pair

2) Your allowFrom / groupAllowFrom entries must be fully numeric

3) You have multiple Telegram accounts (default/agent2/agent3)

Fix (DM case): approve pairing for the right account

If you’re testing in a group instead

A) The group you’re testing in is not actually allowlisted

B) You’re sending as an anonymous admin / sender_chat

The fastest way to end the guessing

Option 1 (recommended for your case): make groups “open”, remove sender allowlists

Important safety note

Quick fix (make exec run in sandbox)

If that then fails because sandboxing/Docker is off

If you intentionally want exec on the gateway host

1) Allow the skill in that group

2) Allow exec for sandboxed sessions (recommended: do it via a dedicated agent)

Safer approach (only this group gets exec)

Fast “global” approach (all sandboxed groups get exec — risky)

What it says (key bits)

What to do (pick one)

Option A (safer; recommended for groups): run exec in sandbox, not on the gateway host

Option B (host exec from that group session): allow Elevated for Telegram (risky in open groups)

1) Turn on sandboxing for non-main sessions (groups)

2) Make exec run in the sandbox by default

3) Allow mcporter in that Telegram group

4) Restart (and optionally recreate sandboxes)

5) Verify

1) Elevated is still blocked (but that’s fine)

2) If mcporter still errors, it’s likely a “binary not present in sandbox” / workspace access issue

Option 1 (recommended): route this group to agent3

Option 2: install/enable mcporter in the main workspace

1) Make sure agentId: "durian" / "durianpro" actually exist as agents

2) Your peer.id must match the exact Telegram chat.id

3) Multi-account gotcha: omit accountId = default account only

4) Expected behavior: routing change creates a new session key

1) The group id in the binding doesn’t match the real chat.id

2) AccountId mismatch (multi-account Telegram)

Next step (fastest to verify)

Best quick check: tail full logs while sending a message

Enable Telegram debug diagnostics (targeted, better than “debug everything”)

Fallback to get the group id without relying on OpenClaw logs

1) The messages aren’t reaching this gateway

2) Telegram isn’t emitting inbound logs at your current settings

3) Get a quick health view of Telegram runtime

Turn on Telegram inbound logging (recommended)

Note on openclaw channels logs --channel telegram

If the bot replies, but logs show nothing

If the bot does NOT reply in Telegram

Fix: lower the file log level + enable Telegram payload diagnostics

If it still only shows WARN after that

1) Disable sandbox (host mode)

2) Make exec run on the host (gateway)

3) Fix the binding for that group (peer + accountId)

4) If you still hit “not authorized” in group

What this unlocks

If you want allowlist mode (only some users can run commands/skills)

If you want open group (everyone can talk to the bot)

Agent binding for this group (durian bot → durian agent)

Minimal config for “anyone in this group can trigger mcporter via normal text”

Host mode (no sandbox): make sure mcporter can run exec

1) Grab the raw-update log line for a mentioned message

2) Common causes (based on what we see in raw-update)

Fix options

Quick fix (open that Telegram account for groups)

Alternative (keep allowlist, just add this user)

Fix

What to do

Quick fix (open groups for the durian Telegram account)

Alternative (stay allowlist-based)

Your group is configured as “mcporter-only”

Is it bad?

Common causes

How to “fix” / silence it

The main knob

How it behaves

1) Grab your Telegram numeric user id (`from.id`)

1) `dmPolicy: "pairing"` means DMs will still be blocked until you pair

2) Your `allowFrom` / `groupAllowFrom` entries must be fully numeric

2) Allow `exec` for sandboxed sessions (recommended: do it via a dedicated agent)

Option 1 (recommended): route this group to `agent3`

Option 2: install/enable `mcporter` in the `main` workspace

1) Make sure `agentId: "durian"` / `"durianpro"` actually exist as agents

2) Your `peer.id` must match the exact Telegram `chat.id`

3) Multi-account gotcha: omit `accountId` = default account only

1) The group id in the binding doesn’t match the real `chat.id`

Note on `openclaw channels logs --channel telegram`

2) Make `exec` run on the host (gateway)

1) Grab the `raw-update` log line for a mentioned message

Quick fix (open groups for the `durian` Telegram account)

1) `streaming: "off"`

2) `streaming: "partial"` (default)

3) `streaming: "block"`

4) `streaming: "progress"`