Silent Bot in Group Chat: A Case Study in Chat Platform Integration

The Setup

I have a personal AI assistant named Bolt, built on OpenClaw, that I use via Telegram. It works perfectly in direct messages: responsive, fast, no issues. But when I added it to a group chat so other people could interact with it too, nothing happened. Not even when I explicitly mentioned it with an @-mention.

The problem seemed straightforward. Telegram bots have a Privacy Mode setting that controls whether the bot can see all group messages or only ones that mention it. I went to BotFather and disabled privacy mode. Still nothing. I removed the bot from the group and re-added it. Still nothing. I even created an entirely new group. Same result.

This is the story of how what looked like a simple configuration toggle was actually a two-layer authorization problem, and how understanding OpenClaw’s channel architecture was the key to fixing it.

The Investigation

Step 1: Checking the Bot Status

Running openclaw channels status showed something interesting:

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

The keyword was groups:unmentioned. OpenClaw was receiving the group messages, but silently dropping them. This told me the problem wasn’t at the Telegram API level, the bot could see the messages. It was being filtered somewhere inside OpenClaw.

Step 2: Understanding OpenClaw’s Channel Architecture

OpenClaw uses a layered authorization system for each channel:

1. Platform-level permissions (Telegram BotFather settings)
2. Channel configuration (your OpenClaw config file)
3. DM Policy: who can send direct messages
4. Group Policy: who can send messages in groups
5. Sender Allowlists: explicit user IDs that are authorized
6. Mention Behavior: whether @mentions are required

Each layer acts as a gate. If any gate is closed, the message doesn’t reach the bot.

Step 3: What I Missed

I had only configured:

"telegram": {
  "enabled": true,
  "groups": {
    "*": {
      "requireMention": false
    }
  },
  "botToken": "..."
}

Setting requireMention: false and disabling privacy mode should have been enough in theory. But OpenClaw’s default groupPolicy is allowlist, and I had never set allowFrom or groupAllowFrom for the Telegram channel. Without at least one authorized sender ID, every group message was silently rejected, regardless of mention status or privacy mode.

The Fix

The solution required two changes to the OpenClaw configuration:

"telegram": {
  "enabled": true,
  "allowFrom": ["YOUR_USER_ID"],
  "groupAllowFrom": ["YOUR_USER_ID"],
  "groups": {
    "*": {
      "requireMention": false
    }
  },
  "botToken": "..."
}

What Each Field Does

• allowFrom: Authorizes specific user IDs for direct messages. Uses numeric Telegram user IDs.
• groupAllowFrom: Authorizes specific user IDs in group chats. If not set, falls back to allowFrom.
• groups.*.requireMention: When false, the bot responds to all group messages without needing an @-mention.
• BotFather /setprivacy: Must be set to Disabled so Telegram sends all group messages to the bot.

The Two-Layer Gate

This is the key insight that took hours to uncover:

Layer	Where	What It Controls
Telegram Platform	BotFather	Whether Telegram sends non-mentioned messages to the bot
OpenClaw Sender Auth	Config file	Whether OpenClaw accepts the message from that sender

Privacy mode is the first gate at the Telegram infrastructure level. Group sender authorization is the second gate inside OpenClaw. Both must be open for group messages to work. Disabling privacy mode but having an empty allowlist is like unlocking the front door but not having a key to the inner door.

Getting Your Telegram User ID

You’ll need your numeric Telegram user ID for the allowlist:

1. DM your bot
2. Run openclaw logs --follow
3. Look for from.id in the log entry

Or use the Bot API directly:

curl "https://api.telegram.org/bot<token>/getUpdates"

Lessons Learned

1. Check the logs first. The groups:unmentioned status was the clue that messages were being received but filtered.
2. Understand the authorization layers. Platform permissions and application permissions are separate gates.
3. Default policies are restrictive. OpenClaw defaults to groupPolicy: "allowlist" for security. You must explicitly authorize senders.
4. Restart after config changes. OpenClaw detects config changes and reloads automatically, but a full restart is more reliable.
5. Remove and re-add the bot. After changing privacy mode in BotFather, you need to kick the bot and re-add it for Telegram to apply the change to existing groups.

Conclusion

What seemed like a simple “bot won’t respond in group” issue turned into a deeper lesson about platform architecture. The fix was straightforward once I understood that Telegram’s privacy mode and OpenClaw’s group sender authorization are two separate gates, and both need to be open.

If you’re building with OpenClaw and running into similar issues, check your allowlists first. They’re often the silent culprit.