Use your personal Telegram account from your coding agent. The same bundle works in three kinds of clients:
- Codex — installed as a plugin from a local marketplace
- Grok Bot / Cursor (custom MCP) — registered as a plain local stdio MCP server
- Any Agent Plugins 1.0.0 client — loaded from the portable
plugin.json+mcp.json
This plugin lets your agent:
- summarize chats
- search recent messages live, or search cached chat history for repeat/broad/old lookups
- sync recent chat history into a local cache once, then summarize, search, and aggregate locally to reduce repeated Telegram API calls (see the cache section below — first sync covers the newest N messages; older backfill is not yet exposed)
- draft and send replies
- triage unread threads
- manage groups/channels
- work with media, drafts, reactions, polls, and scheduled messages
If you just want the shortest path:
- Create Telegram API credentials at
my.telegram.org/apps - Run the login wizard once (
codex-telegram login) - Hook the server into your client:
- Codex: install the plugin from your local marketplace, then use
@Telegramin a fresh thread - Grok Bot / Cursor: add a custom stdio MCP server that runs
uv run --project <repo>/telegram/mcp_server codex-telegram serve
- Codex: install the plugin from your local marketplace, then use
The exact commands are below. The Python CLI is still named codex-telegram
for historical reasons; it is the same server regardless of which client
launches it.
- Python 3.11+
uv- a real Telegram user account
- your own Telegram
api_idandapi_hash - for the Codex path: Codex CLI / Codex app
- for the Grok Bot / Cursor path: any client that can register a local stdio MCP server
Go to https://my.telegram.org/apps
This is the exact flow:
- Log in with your phone number
- Enter the Telegram login code
- Open
API development tools - Fill the form with something sane, for example:
App title:Telegram Agent PluginShort name:codextelegrampluginPlatform:DesktopURL:https://github.com/bchewy/telegram-agent-pluginDescription:Personal Telegram MCP
- Submit
- Copy:
api_idapi_hash
Important:
- this is not BotFather
- you want
my.telegram.org/apps - the plugin expects your API credentials, not a shared developer key
This plugin uses Telegram user-account MTProto auth, not the Bot API. Login is
a one-time CLI step; after it succeeds, the session is stored locally (keyring
or encrypted file) and the MCP server does not need api_id/api_hash in
its environment.
From a repo checkout:
uv run --project ./telegram/mcp_server codex-telegram loginYou will be prompted for:
Telegram API IDTelegram API hash- phone number in E.164 format
- the Telegram login code
- 2FA password, if your account uses it
Successful output looks like:
{'ok': True, 'storage': 'keyring', 'user_id': 123, 'username': 'yourname', 'display_name': 'Your Name', 'phone': '+15555555555'}
If you already installed the plugin into Codex and want to authenticate the installed bundle instead of a checkout, see the Codex section below.
A Codex marketplace is a catalog of plugins. Its interface.displayName is the
dropdown label in Codex, while this plugin's interface.displayName is the
installable item shown inside that marketplace.
For a single local selector, keep all local plugin entries in one user-level
marketplace at ~/.agents/plugins/marketplace.json. Do not keep a repo-local
.agents/plugins/marketplace.json active for this checkout unless you
intentionally want Codex to show this repository as a separate marketplace.
This repo's plugin bundle is telegram/. In the shared Local Plugins
marketplace, the plugin should be installed as:
codex plugin add telegram@localThe matching WhatsApp plugin uses the same model: one Local Plugins
marketplace, separate telegram and whatsapp plugin entries.
For checkouts under ~/dev, the relevant plugins entries look like this.
Preserve any other plugins already present in your local marketplace file.
{
"name": "local",
"interface": {
"displayName": "Local Plugins"
},
"plugins": [
{
"name": "telegram",
"source": {
"source": "local",
"path": "./dev/telegram-agent-plugin/telegram"
},
"policy": {
"installation": "AVAILABLE",
"authentication": "ON_INSTALL"
},
"category": "Productivity"
},
{
"name": "whatsapp",
"source": {
"source": "local",
"path": "./dev/codex-whatsapp-plugin/whatsapp"
},
"policy": {
"installation": "AVAILABLE",
"authentication": "ON_INSTALL"
},
"category": "Productivity"
}
]
}This repo is designed to be installed from the shared local marketplace instead of registering itself as a separate marketplace.
If your ~/.agents/plugins/marketplace.json already includes this checkout,
install the plugin with:
codex plugin add telegram@localIf the local marketplace does not include it yet, add a telegram entry that
points at this repo's telegram/ directory, then rerun the command above. Keep
the marketplace name as local and the display name as Local Plugins if you
want it grouped with your other local plugins.
Open a fresh Codex session after installing. Old threads can miss newly installed plugin, skill, and MCP context.
In Codex:
- Open
/plugins - Open
Telegram - Make sure it looks like the screenshot above
- Make sure the bundled skills are enabled
You should see:
Telegram LoginTelegram SummarizeTelegram Triage UnreadTelegram SearchTelegram AggregateTelegram SendTelegram Manage GroupsTelegram Media Inspect- bundled MCP server:
telegram_personal
Important: start a fresh thread after installing. Old threads can miss newly installed plugin/skill context.
If you skipped the checkout login in Step 2 and want to log in against the bundle Codex installed, run this exact command:
uv run --project "$(
python3 - <<'PY'
from pathlib import Path
candidates = [
p for p in Path.home().glob('.codex/plugins/cache/*/telegram/*/mcp_server')
if p.is_dir()
]
if not candidates:
raise SystemExit('No installed Telegram plugin bundle found under ~/.codex/plugins/cache')
print(max(candidates, key=lambda p: p.stat().st_mtime))
PY
)" codex-telegram loginStart a fresh Codex thread and try one of these:
@Telegram summarize my unread Telegram messages from today
@Telegram find Telegram messages from Alice about the launch
@Telegram cache the Design chat, then search it for launch blockers from last month
@Telegram draft a Telegram reply to the design thread
@Telegram watch this Telegram bubble and transcribe what it says
Or call the bundled skills directly:
$telegram:telegram-summarize summarize my unread Telegram messages from today
$telegram:telegram-search find messages from Alice about launch
$telegram:telegram-aggregate show cached weekly message volume for the Design chat this quarter
$telegram:telegram-send draft a reply to the latest message in Saved Messages
Codex registers the skills under the plugin namespace:
telegram:telegram-logintelegram:telegram-summarizetelegram:telegram-triage-unreadtelegram:telegram-searchtelegram:telegram-aggregatetelegram:telegram-media-inspecttelegram:telegram-sendtelegram:telegram-manage-groups
The bundled server is a normal local stdio MCP server, so any client that supports custom MCP servers (Grok Bot, Cursor, Claude Desktop, etc.) can use it directly — no Codex plugin machinery required.
git clone https://github.com/bchewy/telegram-agent-plugin.git
cd telegram-agent-plugin
uv sync --project ./telegram/mcp_serveruv run --project ./telegram/mcp_server codex-telegram loginSame wizard as Step 2 above: API ID and hash from my.telegram.org/apps,
phone number, login code, 2FA password if set. The session lands in the OS
keyring or in ~/.config/codex-telegram/session.enc.
Add a local stdio MCP server in your client with:
- command:
uv - args:
run --project /absolute/path/to/telegram-agent-plugin/telegram/mcp_server codex-telegram serve - env (optional):
CODEX_TELEGRAM_MASTER_KEY— only if your session is stored in the encrypted file (no OS keyring) and the key is not otherwise available to the server processTELEGRAM_MTPROXY_HOST/TELEGRAM_MTPROXY_PORT/TELEGRAM_MTPROXY_SECRET— only on networks that block direct Telegram MTProto (see troubleshooting)
Telegram API credentials (TG_API_ID / TG_API_HASH) are not required in
the MCP env after login; the stored session already carries them.
In JSON-config clients (for example Cursor's mcp.json), the equivalent entry
looks like:
{
"mcpServers": {
"telegram_personal": {
"command": "uv",
"args": [
"run",
"--project",
"/absolute/path/to/telegram-agent-plugin/telegram/mcp_server",
"codex-telegram",
"serve"
]
}
}
}Use an absolute path for --project. Custom MCP servers are often spawned
with an unrelated working directory, so relative paths break.
From the shell:
uv run --project ./telegram/mcp_server codex-telegram whoamiFrom the agent, in a fresh conversation, ask it to call the get_me tool (or
telegram_diagnostics for a fuller runtime/auth/cache report). You should see
your own account's user id, username, and display name.
- Tools error with "no session found": the server subprocess cannot see
the session that
loginstored. Make sure the client runs the server as the same OS user that ranlogin. If the session went to the encrypted file instead of the keyring, setCODEX_TELEGRAM_MASTER_KEYin the server's env (andCODEX_TELEGRAM_CONFIG_DIRtoo, if you overrode it during login). - Server registered but tools don't show up: start a fresh thread / conversation after adding the MCP server. Most clients only load new servers into new sessions.
- Connection hangs or times out on restricted networks: some hosted or
sandboxed environments block direct Telegram MTProto connections (Telegram's
data centers are raw-TCP endpoints, not HTTPS). In that case Telethon needs a
proxy path. This server supports an MTProxy configured entirely via env vars:
set
TELEGRAM_MTPROXY_HOST,TELEGRAM_MTPROXY_PORT, andTELEGRAM_MTPROXY_SECRETtogether (on both thelogincommand and the MCP server env). Treat the proxy secret like a credential: pass it through your client's env configuration, never commit it. For SOCKS or other proxy types, see the Telethon proxy docs. - First
uv runis slow:uvresolves and builds the project virtualenv on first launch. If your client enforces a short startup timeout, runuv sync --project ./telegram/mcp_serveronce beforehand.
The installable package is the telegram/ directory. It ships two manifest
sets side by side, so the same directory loads in Codex and in any client that
implements the portable Agent Plugins 1.0.0
format:
| File | Consumer | Purpose |
|---|---|---|
plugin.json |
Agent Plugins clients | Portable manifest ($schema = https://agent-plugins.org/schemas/1.0.0/plugin.schema.json, closed field set) |
mcp.json |
Agent Plugins clients | Portable MCP config (stdio server launched via uv, ${PLUGIN_ROOT}/${PLUGIN_DATA} placeholders) |
skills/<name>/SKILL.md |
Both | Agent Skills, discovered as immediate children of skills/ by both formats |
.codex-plugin/plugin.json |
Codex | Codex-native manifest, including marketplace interface metadata (display name, logo, screenshots, prompts) |
.mcp.json |
Codex | Codex-native MCP config, including Codex-only fields (env_vars passthrough allowlist, startup_timeout_sec, tool_timeout_sec) |
Notes on the split:
- Codex does not currently document an Agent Plugins
extensionsnamespace, so its UI/marketplace metadata stays in.codex-plugin/plugin.jsoninstead of being duplicated under an inventedextensionskey. If Codex publishes a reverse-domain namespace later, that metadata can move into the portable manifest'sextensionsfield. - The portable
mcp.jsondeclares no secret values. Telegram credentials come from the login wizard (keyring / encrypted session file), not from the package. TheTG_API_ID-style environment overrides listed below reach the server through Codex'senv_varspassthrough; other clients control their own base subprocess environment, and the server works without them once you have logged in. - The portable config sets
UV_PROJECT_ENVIRONMENT=${PLUGIN_DATA}/uv-envsouvbuilds the virtualenv in the client-managed writable data directory instead of inside the (possibly read-only) installed package. - Shared metadata (
name,version,author,license, ...) must stay identical acrossplugin.jsonand.codex-plugin/plugin.json, and the two MCP configs must launch the same server command. The test suite enforces this (tests/telegram_mcp/test_plugin_structure.py), and also validates the portable files against the vendored Agent Plugins 1.0.0 schemas.
An Agent Plugins client loads the package by reading root plugin.json,
discovering skills under skills/, and starting telegram_personal from root
mcp.json. Codex keeps using .codex-plugin/plugin.json and .mcp.json
exactly as before; nothing about the Codex install flow changed.
# show storage status
uv run --project ./telegram/mcp_server codex-telegram storage
# inspect the authenticated account
uv run --project ./telegram/mcp_server codex-telegram whoami
# log out / clear the stored session
uv run --project ./telegram/mcp_server codex-telegram logout
# run tests (run from telegram/mcp_server so the pytest config and coverage
# settings in its pyproject.toml are picked up; this also writes
# telegram/coverage/coverage.xml for Plugin Eval)
cd telegram/mcp_server && uv run pytestuv run --project "$(
python3 - <<'PY'
from pathlib import Path
candidates = [p for p in Path.home().glob('.codex/plugins/cache/*/telegram/*/mcp_server') if p.is_dir()]
if not candidates:
raise SystemExit('No installed Telegram plugin bundle found under ~/.codex/plugins/cache')
print(max(candidates, key=lambda p: p.stat().st_mtime))
PY
)" codex-telegram whoamiThe login wizard stores the Telegram session in:
- the OS keyring, if available
- otherwise an encrypted file at
~/.config/codex-telegram/session.enc
CODEX_TELEGRAM_SESSION also exists, but it is intended for test/CI use only. It injects a raw StringSession directly and bypasses the normal keyring / encrypted-file flow.
If the OS keyring is unavailable:
# preferred: let the login flow prompt if keyring is unavailable
uv run --project ./telegram/mcp_server codex-telegram loginor:
read -rsp "Telegram session master key: " CODEX_TELEGRAM_MASTER_KEY; echo
export CODEX_TELEGRAM_MASTER_KEY
uv run --project ./telegram/mcp_server codex-telegram login
unset CODEX_TELEGRAM_MASTER_KEYDo not pass the master key as a CLI flag. It ends up in shell history and ps.
| Variable | Purpose |
|---|---|
TG_API_ID |
Telegram API ID used for login/session bootstrap. |
TG_API_HASH |
Telegram API hash used for login/session bootstrap. |
CODEX_TELEGRAM_MASTER_KEY |
Encrypts/decrypts the fallback session file when the OS keyring is unavailable. |
CODEX_TELEGRAM_SESSION |
Test/CI-only raw StringSession injection. Avoid using this for normal local installs. |
CODEX_TELEGRAM_CACHE_ENCRYPT |
Optional: set to 1 to encrypt the local SQLite message cache. Requires pysqlcipher3 plus CODEX_TELEGRAM_MASTER_KEY. |
CODEX_TELEGRAM_ALLOW_DESTRUCTIVE |
Must be set to 1 plus confirm=True on the tool call before destructive tools like delete_chat, delete_messages, or logout will run. |
CODEX_TELEGRAM_UPLOAD_DIR |
Upload sandbox for send_* and set_profile_photo. Files outside this directory require allow_arbitrary_path=True. |
CODEX_TELEGRAM_CONFIG_DIR |
Optional: overrides the config directory that stores the encrypted session file (default ~/.config/codex-telegram). |
CODEX_TELEGRAM_MEDIA_SCRIPTS_DIR |
Optional: overrides the directory containing the telegram-media-inspect scripts used by inspect_message_media. |
TELEGRAM_MTPROXY_HOST |
Optional: MTProxy hostname for networks that block direct MTProto. All three TELEGRAM_MTPROXY_* vars must be set together. |
TELEGRAM_MTPROXY_PORT |
Optional: MTProxy port. All three TELEGRAM_MTPROXY_* vars must be set together. |
TELEGRAM_MTPROXY_SECRET |
Optional: MTProxy secret. Treat it like a credential — env only, never commit it. All three TELEGRAM_MTPROXY_* vars must be set together. |
XDG_CACHE_HOME |
Optional (standard XDG var): changes where the local message cache lives (default ~/.cache/codex-telegram/cache.db). |
The local SQLite cache lives at ~/.cache/codex-telegram/cache.db and is per chat.
Use live search for quick recent lookups or when you do not know the dialog yet. Use the cache when the dialog is known and the task is broad, old, repeated, exhaustive, a summary, or an aggregate.
cache_statusshows which chats are cached, message counts, and last sync times.sync_chat_cache(chat_ref)incrementally adds new messages for one chat. Usefull=Trueonly when you intentionally want to rebuild that chat’s cache. The first sync of a chat bootstraps by iterating messages withiter_messages(limit=max_messages_per_batch)(default 5000) — for chats larger than that batch, the response setsolder_history_uncached: trueand exposesoldest_fetched_idso callers can detect the cap; older history is not currently backfilled by this tool.search_cache(chat_ref, query, from_user, min_date, max_date, auto_sync_seconds=600, compact=True)searches locally and can auto-sync the chat first if the cache is missing or stale. Usecompact=Truefor token-efficient previews; usenext_offsetto continue paginated results.summarize_chat_history(chat_ref, min_date, max_date, chunk_index=0)returns SQL-paginated cache-backed chunks for map-reduce summaries.aggregate_cache(chat_ref, min_date, max_date, group_by="day|week|sender")returns local counts without re-querying Telegram.
For unknown-dialog searches, first use live search or list_dialogs to identify candidate chats, then sync/search those chats through the cache.
If you want the cache encrypted at rest, install pysqlcipher3, set CODEX_TELEGRAM_CACHE_ENCRYPT=1, and provide CODEX_TELEGRAM_MASTER_KEY.
Use the telegram_diagnostics MCP tool when the plugin may be running from a stale installed bundle, when auth is unclear, or when you want to verify whether the local message cache is encrypted. It returns the package version, plugin root, session-storage state, cache path, cache size, and cache encryption status without requiring a working Telegram login. Pass include_account=True if you also want it to attempt an authenticated account check.
Open a fresh Codex thread first. Plugin and skill context can lag in older threads.
Run the login command from Step 2.
You have not completed the login wizard yet, or you logged in under a different environment/user.
Direct Telegram MTProto (raw TCP to Telegram's data centers) is blocked in
some hosted agent environments and corporate networks. If login or the MCP
server cannot connect, route through an MTProxy by setting
TELEGRAM_MTPROXY_HOST, TELEGRAM_MTPROXY_PORT, and
TELEGRAM_MTPROXY_SECRET together in the environment of both the login
command and the MCP server. Keep the secret out of committed files. For other
proxy types (SOCKS5, HTTP), see the
Telethon proxy docs.
Telegram is rate-limiting the action. Short waits retry automatically. Longer waits surface as tool errors.
Telegram restricted the account for spammy behavior. That is an account-level Telegram restriction, not a plugin crash.
Do not rely on that alone. Plugin-bundled MCP servers can be present at runtime even if codex mcp list is incomplete or another manual MCP server name collides. The stronger checks are:
/pluginsshowsTelegraminstalled- the plugin page lists
telegram_personal - a fresh thread can use
@Telegram
If the OS keyring fails, rerun login and let it prompt, or pre-set CODEX_TELEGRAM_MASTER_KEY.
When you invoke a Telegram skill or MCP tool, your agent receives raw chat content and metadata from the response payload. That can include message text, sender names, captions, usernames, reactions, and file metadata.
If you would not paste the content into an agent prompt directly, do not summarize or process it through this plugin.
- This is a user-account integration. A leaked
StringSessionis effectively full account access. - If you think the session leaked, revoke it from an official Telegram client immediately.
- Telegram can rate-limit or restrict accounts using aggressive third-party automation.
- Read-only summarization of your own chats is the lowest-risk use case.
- QR login is intentionally not implemented here.
telegram/: the plugin bundle (single source of truth)plugin.json: portable Agent Plugins 1.0.0 manifestmcp.json: portable Agent Plugins 1.0.0 MCP server declarationmcp_server/: Python package and MCP serverskills/: skill files loaded by the plugin (both formats discoverskills/<name>/SKILL.md)assets/: icon, logo, screenshots referenced by the Codex manifest.codex-plugin/plugin.json: Codex-native plugin manifest (marketplaceinterfacemetadata lives here).mcp.json: Codex-native MCP server declaration (Codex-onlyenv_vars/timeout fields live here)
tests/telegram_mcp/: server tests plustest_plugin_structure.py, which validates the portable manifests against the vendored Agent Plugins schemas and keeps the Codex and portable files in sync- Local marketplace registration lives outside this repo in
~/.agents/plugins/marketplace.json