• 6 min read

Debugging OpenClaw: Why Your Bot Won't Respond in Telegram Groups

You set up OpenClaw. It works perfectly in DMs. You add it to a Telegram group.

Silence.

You type messages. You mention the bot. You try different topics. Nothing.

The gateway logs look clean. No errors. No crashes. The bot just... ignores you.

I've been through this exact scenario more times than I'd like to admit. Here's everything I've learned about why OpenClaw goes silent in Telegram groups — and how to fix it systematically.

The frustrating part: it's never one thing

Unlike a crash or an API error, a silent bot gives you zero feedback. There's no stack trace to follow. The bot simply doesn't respond, and you're left guessing which of the dozen configuration layers is swallowing your message.

After debugging this repeatedly, I've identified the most common failure points — roughly in order of how often they bite.

1. Group privacy mode is eating your messages

This is the #1 cause and the easiest to miss.

By default, Telegram bots run in "privacy mode" — they only receive messages that explicitly mention them or are replies to their messages. Everything else is invisible to the bot.

Fix: Talk to @BotFather → /mybots → select your bot → Bot Settings → Group Privacy → Turn off.

After changing this, you need to remove and re-add the bot to the group. Telegram caches the privacy setting at the time the bot joins.

2. groupPolicy is blocking you

OpenClaw has a layered permission system for groups. In your openclaw.json:

{
  "channels": {
    "telegram": {
      "groupPolicy": "allowlist",
      "groupAllowFrom": ["your-telegram-id"]
    }
  }
}

If groupPolicy is "allowlist" and your Telegram ID isn't in groupAllowFrom, the bot receives your message but deliberately ignores it.

How to check: Run openclaw status and look at the channel config. Or check the gateway debug logs — with logging.level: "debug", you'll see messages being received but filtered.

Fix: Add your Telegram user ID to groupAllowFrom. You can find your ID by sending a message to @userinfobot.

3. requireMention is true (and you're not mentioning)

Each group — and each topic within a forum group — can have requireMention set independently:

{
  "groups": {
    "-100XXXXXXXXXX": {
      "requireMention": true,
      "topics": {
        "2": {
          "requireMention": false
        }
      }
    }
  }
}

If requireMention is true at the group level and you're typing in a topic that doesn't override it to false, the bot will only respond when you @mention it.

The trap: You might have set requireMention: false for topic 2 but forgot topic 1 (General). Or the group-level default is true and you assumed topics inherit false.

Fix: Set requireMention: false explicitly for each topic you want the bot to respond in freely.

4. The topic isn't enabled

Forum groups in Telegram use topics. Each topic needs to be explicitly enabled in your config:

{
  "topics": {
    "1": { "enabled": true },
    "2": { "enabled": true, "requireMention": false }
  }
}

If a topic isn't listed or has "enabled": false, the bot won't respond there — even if the group itself is enabled.

Gotcha: Topic IDs aren't always obvious. The "General" topic is usually "1", but custom topics have numeric IDs that you need to find from the Telegram API or your gateway logs.

5. Bot isn't an admin (or lacks permissions)

For forum groups specifically, the bot often needs admin privileges to:

  • Read messages in all topics
  • Send messages in all topics
  • Manage topics (if you want it to create them)

A non-admin bot in a forum group might only see the General topic, or nothing at all.

Fix: Make the bot an admin with at least "Read Messages" and "Send Messages" permissions.

6. The gateway isn't actually running

This sounds obvious, but I've spent 20 minutes debugging config when the gateway had silently crashed and restarted with a different session.

Quick check:

openclaw status
openclaw gateway status

If it recently restarted, check why: journalctl -u openclaw-gateway --since "1 hour ago".

7. Message format edge cases

A few less obvious ones:

  • Edited messages: By default, OpenClaw doesn't process edited messages. If you edit a typo and expect a response, it won't come.
  • Forwarded messages: Depending on config, forwarded messages might not trigger the bot.
  • Media-only messages: An image without caption text might not trigger a response if the bot doesn't have image processing configured.

My debugging checklist

When the bot goes silent in a group, I now run through this in order:

  1. ✅ openclaw status — is the gateway alive?
  2. ✅ Check debug logs — is the message being received at all?
  3. ✅ BotFather → Group Privacy → Off (and rejoin the group after changing)
  4. ✅ groupPolicy + groupAllowFrom — am I allowed?
  5. ✅ requireMention — at group AND topic level
  6. ✅ Topic enabled: true — is this specific topic active?
  7. ✅ Bot admin permissions in the group
  8. ✅ Send a test message in DM — does the bot respond at all?

Step 8 is the sanity check. If DMs work but groups don't, the problem is 100% in group/topic config. If DMs also fail, it's deeper (auth, model, gateway).

The real lesson

The hardest bugs to debug aren't the ones that throw errors.

They're the ones that silently do nothing.

Every time I've debugged a "silent bot in groups" issue, the root cause was a single configuration flag buried three levels deep. No error message. No warning. Just silence.

That's why I turned this debugging experience into a permanent checklist. The 8 steps above have saved me hours. Maybe they'll save you some too.