A deep comparison of the official Anthropic Claude Code Telegram plugin vs. how OpenClaw and Hermes consume/adapt it, plus a native design recommendation for Grok.
The reference implementation. Mature, extremely careful security model, battle-tested zombie defense, pairing flow, and permission relay via Telegram DMs.
OpenClaw ships its own complete Telegram channel implementation in extensions/telegram/. It has a dedicated bot runtime, ingress spool, outbound delivery, threading, approvals, media handling, polling/webhook monitors, native commands, and deep plugin-sdk integration. Not a reuse of Claude's code.
Hermes has a first-class gateway/platforms/telegram.py + telegram_network.py. Built on python-telegram-bot with heavy emphasis on delivery reliability (text batching, noise filtering, forum support, conflict handling, DoH-based IP fallbacks for censored networks, advanced media handling).
How the core Telegram channel capabilities are implemented or adapted across the three systems.
| Capability | Claude Official | OpenClaw (via gstack) | Hermes (via gstack) | Grok (current / planned) |
|---|---|---|---|---|
| Core Implementation | ✓ Full grammy + MCP server.ts (Claude channel model) | Independent full implementation (extensions/telegram + plugin-sdk) | Independent gateway platform (gateway/platforms/telegram.py + network layer) | Currently reuses Claude cache; native fork planned |
| State Directory | ~/.claude/channels/telegram-* | Can be pointed via env + skill rewrites | Rewritten paths in skills | Planned: ~/.grok/channels/telegram-* |
| Pairing + Access Control | Excellent (access.json, pairing codes, dmPolicy, allowFrom) | Same (skill adapts) | Same (skill adapts) | Planned to keep verbatim + Grok paths |
| Permission Relay (DM approvals) | Full inline keyboard + y/n reply flow | Available if Claude-style notifications emitted | Available if emitted | Optional / less central (Grok prefers flags) |
| Zombie / PID Defense | Outstanding (PID file + SIGHUP + orphan watchdog + 409 retry) | Inherited from server | Inherited | Keep verbatim in native port |
| Skills UX | /telegram:access + /telegram:configure | Rewritten paths + tool names via host | Rewritten (terminal, patch, etc.) | Native Grok skills + /telegram:* |
| Attachment / Vision Handling | download_attachment tool + image_path | Depends on host vision | Depends on host | Will need Grok vision alignment |
| Multi-bot Support | TELEGRAM_STATE_DIR per bot | Via env | Via env | Planned identical |
| Plugin / Distribution Model | claude-plugins-official marketplace + --channels flag | gstack skill adaptation layer | gstack skill adaptation layer | Native grok plugin or first-class channel (planned) |
Both projects have built substantial, independent Telegram channel/gateway code rather than just wrapping the Claude one.
The official Claude implementation is one of the most carefully engineered channel bridges in the agent space. Key invariants that should be preserved:
assertAllowedChat + assertSendable gates on every actionTELEGRAM_ENABLE_PERMISSION_RELAY)grok mcp add + env var launch pattern.mcp.json + skills)grok telegram configure <token> one-command setupgrok --channel telegram or equivalent launch helper.claude state