update
May 12, 2026
By Teun
Telegram and Slack bridge brings Codex agents to chat
A new Telegram/Slack interface lets users control local Codex agents from chat instead of the command line. The tool supports session control, directory mapping, approval requests, and keeps chat-to-session links across restarts.
A new Telegram and Slack bridge lets people control local Codex agent sessions from chat, rather than from the command line. The interface is designed for locally running Codex agents and supports many of the same functions as the CLI, according to the project description.
The tool lets users send messages to and from agent sessions, watch thinking status, handle approval requests, and run regex-based auto-approval rules. It can also select directories, start and stop agents, and keep mappings between channels, direct messages, directories, and sessions after restarts.
⚡ New to this?
This is a chat-based control layer for a local coding agent. A local agent is software that runs on your own machine or server, and Codex here refers to an AI coding assistant that can work on files and tasks.
The main idea is that you can manage the agent through Telegram or Slack instead of typing commands in a terminal. That matters because it changes how teams monitor, approve, and resume AI work while keeping the agent tied to specific directories and chat threads.
🦞 OpenClaw angle
If you run self-hosted agents, separate the control plane from the worker process the way this project does. Keep the chat bridge in a private channel or DM, map each directory to one session, and persist that mapping so restarts do not lose context.
If you build a similar tool, make approval requests and stop/start controls explicit commands, not hidden behavior. Also avoid exposing public listening ports or inbound webhooks unless you actually need them; use the messaging platform only as a transport layer.
According to the author, the runtime uses two agent roles. A master agent starts and stops worker agents, manages directory bindings and session context, and maps a specific directory to a specific channel. The worker agent has no predefined task prompt and behaves like a regular Codex coding agent.
The project is aimed at people who want to control local coding agents through a messaging app instead of a terminal. The author said they are using it instead of the CLI even on desktop.
On the security side, the author says the master runtime does not open public listening ports and does not require inbound webhooks. It also does not depend on external services other than Telegram or Slack for transport.
The recommended setup is to use private chats and private channels. After setting up the bot and launching the runtime, users can send any message in the chat, channel, or DM where the bot is present.
From there, the user can connect a directory to that chat, channel, or DM in a free-form dialog and start either a new or existing Codex session for it. Once connected, the session can be used normally through the same chat thread.
The same control-plane commands are available in Telegram and Slack: /help shows command help, /where shows what the chat is connected to, /status shows bot state and session details, /stop stops the current session while keeping the connection, /start resumes it, and /reset disconnects the chat and clears local state.
The project notes one Slack-specific limitation: slash commands are not implemented in the runtime yet. Users should send the same commands as ordinary messages, and if Slack tries to treat /... as a slash command, they should prefix it with a leading space, according to the setup notes.
