Feature request: official Telegram connector for reading selected public channels

Summary

Please add an official Telegram connector/plugin that lets Codex use explicitly selected public Telegram channels and posts as read-only sources.

The primary use case is not controlling Codex through a Telegram bot. It is allowing Codex and recurring Codex workflows to read, search, summarize, and monitor public-channel content with reliable source attribution.

Problem

For many technical, research, civic, and regional communities, Telegram public channels are a primary information source. Today, users must manually copy posts into Codex or build unsupported scrapers and custom bridges.

That creates several problems:

• no supported way to scope access to specific channels;
• unreliable retrieval of post history and new posts;
• loss of canonical post links, timestamps, channel identity, and media context;
• brittle scheduled monitoring;
• unclear authentication, revocation, rate-limit, and privacy behavior;
• avoidable prompt-injection risk when third-party channel content is ingested through ad hoc tooling.

Proposed user experience

A user should be able to install a Telegram connector, select or allowlist specific public channels, and then ask Codex to perform tasks such as:

• “Summarize posts from these channels since yesterday.”
• “Find posts mentioning this project and preserve links to the originals.”
• “Compare how these channels covered the same event.”
• “Monitor these channels daily and report only materially new information.”
• “Extract referenced documents, dates, organizations, and follow-up items.”

Suggested MVP scope

Read capabilities

• Read posts from explicitly selected public channels.
• Retrieve a bounded date range or recent-post window.
• Search channel posts by keyword or topic.
• Preserve channel name, publication timestamp, canonical post URL, and reply/forward context when available.
• Include captions and supported media metadata; optionally process attached images/documents through existing Codex capabilities.

Permissions and safety

• Read-only by default; posting, reacting, joining channels, or sending messages should be out of scope for the MVP.
• Exact channel allowlist visible to the user.
• Granular, revocable authorization with a clear connection-status UI.
• No access expansion from a public channel to private chats, contacts, or unrelated account data.
• Treat all retrieved channel content as untrusted external input and preserve the boundary between source content and instructions to the agent.
• Explicit limits for history depth, polling frequency, rate limits, and retention.

Automation support

• Allow recurring Codex tasks to check selected channels for new posts.
• Deduplicate previously processed posts using stable post identifiers.
• Report canonical links and timestamps in every monitoring result.
• Make “no material changes” a valid quiet outcome so automations do not generate noise.

Acceptance criteria

1. A user can connect Telegram and allowlist one or more public channels.
2. Codex can summarize posts from a requested date range and cite the original post URLs.
3. A recurring task can retrieve only posts newer than its previous successful run without duplicates.
4. Revoking the connector or removing a channel from the allowlist prevents subsequent reads.
5. Private chats, contacts, and non-allowlisted channels remain inaccessible.
6. Retrieved Telegram content cannot silently override agent or user instructions.

Related issues / non-goals

• #21166 requests Telegram as a remote chat interface for Codex CLI.
• #15299 requests inbound MCP notifications routed into an active CLI session.

This request is intentionally different: it asks for Telegram as a supported source connector for public-channel content across Codex/plugin-enabled workflows, including research and recurring monitoring. It does not require Telegram to become the user interface for Codex.

A custom MCP server may be a workaround, but an official connector would provide a consistent permission model, source metadata, revocation behavior, safety boundary, and supported automation contract.