OpenClaw Telegram-Bot-Einrichtung: Befehle, Routing und Multi-Agenten-Sitzungen

Hallo Automatisierungsbauer – wenn du OpenClaw mit Telegram verbindest und dich fragst, wie das Routing tatsächlich funktioniert, wenn Nachrichten aus DMs, Gruppen und Themen einfliegen, bleib dran.

Ich habe die letzten zwei Wochen damit verbracht, OpenClaw über Telegram in drei verschiedenen Setups zu betreiben: persönliche DMs, Teamgruppen und Forenthemen. Keine Demo-Szenarien. Echte Routing-Tests, bei denen ich absichtlich die Sitzungsisolation durchbrochen, es mit gleichzeitigen Anfragen überflutet und beobachtet habe, wie das Gateway mit Multi-Account-Konfigurationen umgeht.

Die Frage, die mich immer wieder beschäftigte: Kann dies tatsächlich saubere Sitzungsgrenzen aufrechterhalten, wenn man mehrere Chats jongliert, oder bricht alles in einen unordentlichen Gesprächsfaden zusammen?

Hier ist, was ich herausgefunden habe, plus die genauen Konfigurationsmuster, die überlebt haben.

Zum Kontext: OpenClaw (früher Moltbot und Clawdbot) erreichte Anfang 2026 über 100.000 GitHub-Sterne als Open-Source-Autonomer KI-Assistent. Erstellt von Peter Steinberger, verbindet es Messaging-Plattformen wie Telegram mit KI-Agenten, die lokal oder auf privaten Servern laufen.

Erstelle einen Telegram-Bot (BotFather)

Every OpenClaw Telegram setup starts with @BotFather, Telegram's official bot creation interface. This hasn't changed since Telegram launched bots — it's still the only way to generate API tokens.

What you'll need:

• Active Telegram account (phone verification required)
• 3 minutes for initial setup
• Bot token stored somewhere secure (I use a password manager)

Step-by-step bot creation

1. Open Telegram and search for @BotFather
   1. Verified account has a blue checkmark
   2. Send /start to see available commands
2. Create new bot with /newbot
   1. Bot name: What users see in conversations (can include spaces)
   2. Username: Must end with bot (e.g., YourProjectBot)
   3. Username must be globally unique across Telegram
3. Save your API token immediately
   1. Format: 123456789:ABCdefGHIjklMNOpqrsTUVwxyz
   2. Treat this like a password — anyone with this token controls your bot
   3. If compromised, use /revoke in BotFather to generate a new one

Critical BotFather settings (optional but recommended):

/setjoingroups  → Allow/deny adding bot to groups
/setprivacy     → OFF = bot sees all group messages
                  ON = bot only sees mentions and commands

I learned this the hard way: if you set privacy to ON and wonder why your bot ignores group messages, that's why. OpenClaw's routing expects full message access by default.

Connect Token + Verify Updates

Getting the token into OpenClaw is where most setup guides stop — but that's where real testing should start.

Basic connection config

OpenClaw supports two token input methods:

Environment variable (quick testing):

export TELEGRAM_BOT_TOKEN="your_token_here"
openclaw gateway

Config file (production approach):

{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "123456789:ABCdefGHIjklMNOpqrsTUVwxyz",
      "dmPolicy": "pairing"
    }
  }
}

Verification test sequence

Here's the sequence I run every time to confirm the Gateway actually sees Telegram updates:

1. Start Gateway with logging:

openclaw gateway --log-level debug

1. Send /start to your bot in Telegram
   1. Should trigger pairing flow if dmPolicy: "pairing"
   2. Check terminal for incoming update logs
2. Monitor update stream:

openclaw logs --follow

Common failure point: Bot token typo. If you see 401 Unauthorized in logs, regenerate the token in BotFather and update your config. Don't waste an hour troubleshooting like I did.

Sicherheitshinweis: Für Produktionseinsätze sollten Sie erwägen, DigitalOceans gehärtetes OpenClaw-Image zu verwenden, das standardmäßig Firewall-Regeln, Container-Isolierung und Nicht-Root-Ausführung umfasst.

Befehlsdesign, das skaliert

Das Befehlsystem von OpenClaw ist der Punkt, an dem die Routing-Logik wichtig wird. Das Gateway erkennt Slash-Befehle über alle Kanäle hinweg, aber Telegram fügt eine eigene Befehls-Autovervollständigungsebene hinzu.

Das offizielle OpenClaw-Repository dokumentiert den vollständigen Befehlssatz, aber nach realen Tests erweisen sich nur wenige als wesentlich.

Kernbefehlsmuster

Dies sind die Befehle, die ich tatsächlich in Produktionsumgebungen verwende (nicht die vollständige Liste — nur das, was im realen Einsatz Bestand hat):

Important: /activation always only affects the current session. To persist it, add it to your config's requireMention settings.

Setting up custom commands in BotFather

This is what makes your bot feel native in Telegram:

1. In BotFather: /mybots → Select your bot → Edit Commands
2. Send command list (one per line):

new - Start fresh sessionstatus - Check session statehelp - Show all commands

1. These appear in Telegram's / autocomplete menu

Reality check: I initially set up 15 commands. After two weeks, I only use 4. Start minimal.

For deeper understanding of Telegram's bot architecture, see the official Telegram Bot tutorial which covers the Bot API fundamentals.

Routing by Chat/User/Topic

This is where OpenClaw's session architecture either makes sense or falls apart. Session keys determine whether conversations stay isolated or bleed together.

Session key structure

OpenClaw generates session keys using this pattern:

agent:<agentId>:telegram:<chatType>:<chatId>[:topic:<topicId>]

Breakdown:

• DMs: All messages from one user → shared main session
• Groups: Each group → isolated session (telegram:group:<chatId>)
• Forum topics: Each topic → separate session (:topic:<threadId> suffix)

Multi-account routing config

Here's a real config I ran for testing three separate Telegram bots routing to different agents:

{
  "channels": {
    "telegram": {
      "accounts": [
        {
          "name": "personal",
          "botToken": "token1...",
          "routing": { "agent": "main" }
        },
        {
          "name": "work",
          "botToken": "token2...",
          "routing": { "agent": "work-agent" }
        },
        {
          "name": "testing",
          "botToken": "token3...",
          "routing": { "agent": "sandbox" }
        }
      ]
    }
  }
}

Each account routes to a separate agent workspace with independent memory and tools. No cross-contamination.

Group routing with mention controls

Default behavior: groups require @mention to trigger responses. Override per-group:

{
  "channels": {
    "telegram": {
      "groups": {
        "*": { "requireMention": true },
        "-1001234567890": { 
          "requireMention": false 
        }
      }
    }
  }
}

Group ID discovery: Add bot to group, send a message, check openclaw logs --follow for the chat.id value (always negative for groups).

Forum topic isolation

Telegram forums add message_thread_id to messages. OpenClaw appends :topic:<threadId> to session keys automatically.

Critical edge case I hit: Topic ID 1 (general topic) requires special handling. OpenClaw omits message_thread_id when sending to topic 1 because Telegram rejects it.

Config example for per-topic system prompts:

{
  "telegram": {
    "groups": {
      "-1003595003457": {
        "requireMention": false,
        "topics": {
          "14": {
            "requireMention": false,
            "systemPrompt": "You are a coding assistant."
          },
          "27": {
            "systemPrompt": "You focus on deployment issues."
          }
        }
      }
    }
  }
}

Each topic maintains isolated conversation history.

Debugging Missed Messages

When messages disappear into the void, it's usually one of these three culprits.

Diagnostic checklist

1. Check BotFather privacy settings

/mybots → Your Bot → Bot Settings → Group Privacy → OFF

1. If ON, bot only sees mentions — not regular messages.
2. Verify group whitelist

openclaw logs --follow | grep "skipping group message"

1. If channels.telegram.groups is defined, unlisted groups are ignored.
2. Confirm bot membership
   1. Bot must be added as a member (not just admin with no read access)
   2. Test: send a message, check if bot's "last seen" timestamp updates
3. Review Gateway logs

openclaw logs --level debug --filter telegram

Common routing failures

Session hygiene checks

I run this sequence weekly to catch routing drift:

# List active sessions
openclaw sessions list
# Check specific session state
openclaw sessions show <sessionKey>
# Force session cleanup (last resort)
openclaw sessions prune --older-than 7d

When sessions leak: If you see context bleeding between chats, it's usually a config error where multiple chats map to the same session key. Review channels.telegram.accounts[].routing.agent settings.

What Actually Worked Long-Term

After two weeks of daily use across three different Telegram setups, here's what survived:

Stable config pattern

{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "env:TELEGRAM_BOT_TOKEN",
      "dmPolicy": "pairing",
      "groups": {
        "*": { "requireMention": true }
      }
    }
  }
}

Why this works:

• DM pairing prevents unauthorized access
• Wildcard group policy with mention requirement = safe defaults
• Token from env var = easier rotation without touching config

What didn't scale

• Custom commands beyond /new, /status, /help — Users forget them
• Per-topic system prompts — Maintenance burden grows fast
• Multiple accounts without clear routing rules — Session chaos

Boundary conditions

OpenClaw Telegram routing is solid for:

• Personal DM automation (single user)
• Small team groups (< 20 active members)
• Forum topics with distinct purposes

It gets messy when:

• You're managing 10+ groups without config discipline
• Users expect instant responses (add queue monitoring)
• Session state matters across Gateway restarts (implement persistence checks)

Security reminder: As noted in security analysis, OpenClaw stores session transcripts and credentials locally. Treat your ~/.openclaw directory as sensitive — use encrypted drives and restrict file permissions.

Wenn OpenClaw + Telegram dich dahin bringt, wo du hin musst, dann nutze es. Halte einfach die Sitzungsschlüssel sauber und wisse, welche Gruppen welchen Agenten erhalten.

Bei Macaron bewältigen wir die gleichen Routing-Herausforderungen automatisch – Sitzungsisolation über Plattformen hinweg, kein manuelles Konfigurationspatching, wenn du Kanäle hinzufügst. Wenn du plattformübergreifendes Routing testen möchtest, ohne jedes Mal bei der Skalierung Konfigurationen neu zu erstellen, probiere es mit einem realen Workflow aus und sieh, wie es mit deinem Setup umgeht.

FAQ

F: Mein Bot antwortet überhaupt nicht auf Gruppennachrichten. Wo sollte ich zuerst nachsehen? BotFather-Datenschutzeinstellungen. Wenn sie auf EIN gestellt sind, sieht der Bot nur direkte @Erwähnungen – alles andere wird stillschweigend ignoriert. Gehe zu BotFather → /mybots → Bot-Einstellungen → Gruppen-Datenschutz → schalte es AUS. Dies ist der häufigste Grund, warum es bei Gruppeneinrichtungen nicht funktioniert.

F: Wie finde ich die Chat-ID meiner Gruppe? Füge den Bot der Gruppe hinzu, sende eine beliebige Nachricht und führe dann openclaw logs --follow aus. Die chat.id erscheint im eingehenden Update – es wird eine negative Zahl für Gruppen sein. Das ist der Wert, den du in deine Whitelist-Konfiguration einträgst.

F: Benötige ich ein separates Bot-Token für jedes Telegram-Konto, das ich route? Ja. Jeder Eintrag in channels.telegram.accounts[] benötigt sein eigenes BotFather-Token. Ein Token, eine Bot-Identität. Wenn du mehrere Bots betreibst und Dinge sich vermischen, erklärt die OpenClaw-Gateway-Konfigurationsreferenz, wie die Isolation auf Kontoebene tatsächlich funktioniert.

F: Forenthemen – muss ich jedes manuell konfigurieren? Nur wenn du systemweite Eingabeaufforderungen pro Thema möchtest. OpenClaw übernimmt die Sitzungsisolation automatisch (:topic:<threadId>-Suffix), sodass Gespräche ohne Konfiguration getrennt bleiben. Eine manuelle Einrichtung ist nur nötig, wenn du unterschiedliches Agentenverhalten pro Thema wünschst.

F: Sitzungen verlieren nach Gateway-Neustarts den Kontext. Ist das normal? Standardmäßig ja – der Sitzungsstatus wird nicht über Neustarts hinweg gespeichert, es sei denn, du hast die Persistenz konfiguriert. Wenn das für deinen Anwendungsfall ein Problem ist, sieh dir den OpenClaw-Quick-Start-Guide für die verfügbaren Persistenzoptionen auf Gateway-Ebene an.

F: Ich richte das auf einem VPS ein. Gibt es Telegram-spezifische Dinge, die ich wissen sollte? Stelle sicher, dass die ausgehenden Verbindungen deines Servers zu api.telegram.org nicht blockiert sind – einige günstige VPS-Anbieter schränken dies ein. Darüber hinaus gelten die üblichen Sicherheitsmaßnahmen: Ausführung ohne Root-Rechte, Firewall-Regeln, Token in Umgebungsvariablen statt fest kodiert. Der OpenClaw-VPS-Bereitstellungsleitfaden deckt die vollständige Einrichtung ab, wenn du von Grund auf beginnst.

F: Ich habe früher Moltbot für Telegram betrieben. Ist die Migration unkompliziert? Meistens ja, aber die Konfigurationsstruktur hat sich geändert. Wenn du auf Konflikte oder unerwartetes Verhalten nach dem Wechsel stößt, lohnt sich ein Blick auf den Moltbot-Telegram-Setup-Vergleich – er zeigt auf, was sich zwischen den beiden geändert hat.