Feature request: official Telegram integration/plugin for Codex CLI
Feature request
Please consider providing an official Telegram integration/plugin for Codex CLI.
Motivation
Codex CLI is already very useful in a terminal-first workflow, but there is currently no official way to connect it to Telegram as a chat interface. Many users run agents on a Mac/Linux machine or a server and want to interact with Codex remotely from their phone without keeping a terminal open.
A Telegram integration would make Codex CLI much more practical for:
- remote coding assistance while away from the computer;
- receiving long-running task notifications and summaries;
- sending follow-up instructions from mobile;
- sharing files, screenshots, voice notes, or quick text prompts into a running coding workflow;
- self-hosted personal assistant setups where Telegram is the main control surface.
Proposed solution
An official plugin could provide a supported bridge between Codex CLI and Telegram Bot API, for example:
- configure with a Telegram bot token and allowed user/chat IDs;
- map Telegram messages to Codex CLI sessions;
- stream or send final responses back to Telegram;
- support file/image attachments when possible;
- expose safe controls for approvals, cancellation, and session reset;
- avoid duplicate polling/webhook instances and document deployment patterns.
Why official support matters
Community wrappers can work, but messaging integrations touch authentication, command execution, file access, and approval flows. An official plugin or documented reference implementation would give users a safer and more reliable path than ad-hoc scripts.
Thanks for considering it.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I think this request has two separable parts:
The second part is the harder contract. If inbound messages do not land in the live CLI/TUI state, Telegram becomes a second controller that can drift from what the terminal process actually sees.
I built Faryo around a narrower version of this workflow: Codex stays running inside tmux on the owner machine, and phone/browser acts as a thin control surface for compact output, short input, approvals/interrupts, and handoff. It is not a Telegram integration and not official Codex support, but it may be a useful comparison for the "phone controls the existing live CLI session" part: https://github.com/Snailflyer/faryo
For your use case, is Telegram itself the required UI, or would a browser/PWA control surface be acceptable as long as it attaches to the existing CLI session?
the part that bites with bridging a coding agent to a chat surface isn't the bot token or webhook dedup, it's session lifecycle. codex sessions live inside the terminal process, so the moment that process restarts or the box reboots, your telegram thread is suddenly talking to a fresh session with no idea what task it was mid-way through. mapping messages to sessions is the easy 80%; making a session survive a reconnect, and not silently fork into three orphaned ones, is where these bridges quietly fall apart. i'd pin down persistence and a stable session id before touching the transport, because the transport is the part of this that's actually well-specified.
@m13v nailed the actual hard part. its not the bot token, its session lifecycle. the moment the process restarts your telegram thread is talking to a fresh session with no memory of the conversation.
i hit exactly this building repowire (a cross-runtime agent mesh with a telegram bot peer). two things made it usable:
it drives codex today via tmux injection (clunky, and the real fix is the native ingress in #15299 / #15355). but the lifecycle and sticky-routing layer is the bit thats easy to underestimate, worth designing for up front if an official plugin happens :slightly_smiling_face: