Telegram channel: a thread sends you a result when you ask, and you answer from the chat

[leorivastech]

This pull request lives in my own fork. It is not a request to merge anything into T3 Code.
It is the public, dated record of work I designed and built myself, with the code in this branch. I first described it in the Ideas section of the T3 Code repository on October 6, 2026 (discussion 16536). If the T3 Code team ever wants it, it is theirs to take; until then it stays here.

This is not a notification system. I have read "notifications are an anti-pattern" and I am not asking to be pinged when something happens. Nothing here fires on its own. The agent sends something only when you tell it to ("send me the report on Telegram when you finish"), and what arrives is the result itself, a file or a message you can act on, not an alert that pulls you back into the app.

Why

At work we use Telegram for everything. When an agent produces something worth showing, a PDF, a chart, a short video, I open T3 Code, find the file and forward it by hand. And when someone answers "ok, now change X", I go back to the app to type it. The chat is already where the conversation is.

What I have working on my fork

It is built, tested, and running on my machine. Set up once in Settings → Integrations → Telegram with your own bot from BotFather:

• Send. One MCP tool, telegram_send: text, or a file that already exists. Images and MP4 show inline, anything else arrives as a document.

  

• Answer. Reply to any message the bot sent and your text becomes a new turn in the thread that sent it, even if that thread was idle.

  

• Pick a thread. /threads lists the open threads, one message each. Reply to the one you want.

  

• Groups can receive. Add the bot to a group, add the id it posts to Settings, and ask for it by name: "send it to the team group". This part is written and covered by tests; I have not tried it against a real group yet.

95-second recording. The settings step is stills from a test build; the rest is a real-time screen recording:

t3-telegram-demo-small.mp4

What I left out on purpose

• Anything automatic. No "turn finished" messages, no mirroring of answers. If that is ever wanted it should be opt-in and a separate decision.
• Voice. No Whisper for incoming voice notes and no TTS for answers. Both are easy to bolt on, but they need an API key or a decent GPU, and I wanted this to work for anyone running T3 Code locally.
• Answers from groups. A reply becomes a prompt for an agent that can run commands on the machine, so only the people you list can answer, and only from their private chat with the bot.
• Making the files. The channel sends what exists. Producing the PDF or the video is the agent's job.

How far this could go

Not part of this change, only where the same shape leads:

• Slack or Teams: the same two halves, a send tool and "a reply goes back to its thread".
• Answering from a group or a topic, limited to the listed people.
• Voice in and out, for those who have the hardware or a key.

How it fits the codebase

One server service (long polling, so nothing has to be reachable from outside), one MCP toolkit, one settings section, one small table in the existing SQLite. The bot token lives in the secret store, like the Bitbucket tokens. A thread sends files from its own workspace; only a full-access thread can send a file from elsewhere on the machine. Mobile needs no new screen. Focused tests and a user guide are written.

Where the code is

• feature/telegram-channel: upstream main as of October 7, 2026 plus this change, one commit (41 files, about 3,490 added lines, tests included).
• mods-telegram: the same plus my mods, which is what I run.

Server tests for the channel, the tool, the settings and the migrations pass on this branch (237), and the web settings tests (593).

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for b833dcb.

This comment will update automatically after the next completed run.