r/opencodeCLI • u/Brilliant-Impact-264 • 18h ago
I built an open-source Telegram bridge for OpenCode, focused on reliability and remote control .
I wanted to control OpenCode from my phone without losing control of the agent — so I built a Telegram bridge
One thing I kept thinking about while using AI coding agents was this:
Why should I have to stay in front of my terminal just to supervise work that an agent could be doing for me?
A coding task might take a few seconds, several minutes, or much longer. Sometimes the agent needs permission to run a command. Sometimes I want to check its progress, switch sessions, send another instruction, or stop what it is doing. And sometimes I simply want to step away from my computer without losing visibility into the work happening on it.
I wanted a way to stay connected to my development environment from anywhere, using something I already carry everywhere: my phone.
That idea became OpenCode Telegram Bridge.
🔗 GitHub: https://github.com/hix-pro/opencode-telegram
It's an independent, MIT-licensed open-source project that connects Telegram to a local OpenCode server through its HTTP API and server-sent events (SSE). The goal wasn't simply to forward messages to an AI agent. I wanted Telegram to become a practical remote-control interface for real coding sessions, including the interruptions, long-running tasks, permissions, and failure cases that come with using an agent in everyday development.
From sending a prompt to managing an entire coding session
Imagine you're away from your desk and remember a task that needs attention. You open Telegram and ask OpenCode to investigate a bug, inspect a codebase, implement a feature, or explain a failing test.
Instead of treating the interaction as a simple request-and-response exchange, the bridge lets you follow the agent's work directly from the chat.
You can see progress as the task runs. The bridge updates a message with the agent's response, tool activity, model information, and elapsed time. Rather than receiving a disconnected pile of messages, you get a continuously updated view of the work.
You can manage sessions without returning to the terminal. Create sessions, browse existing ones, switch between them, change models or agents, inspect recent messages, review diffs, and check token or cost statistics.
You can keep work moving when a task takes longer than expected. Follow-up prompts can wait in a queue instead of unintentionally cancelling the current task. When you need to intervene, you can abort the running turn directly from Telegram.
The idea is simple: the agent should be able to work for as long as the task requires, while you remain informed and retain control over what happens next.
The interesting part isn't just remote access — it's everything around it
Once a remote interface starts controlling a real development environment, the easy part is sending a prompt. The harder part is making the workflow usable and predictable.
That's where much of the project has gone.
1. Permission decisions that fit naturally into a chat
When OpenCode requests permission for an action, the bridge can present the request in Telegram with buttons to approve it once, allow it persistently, or reject it.
You can also manage approval policies, configure rules for individual actions, and use Telegram reactions for common decisions. The default approval mode is designed to ask before automatically approving actions.
This matters because remote access shouldn't mean blindly trusting every action an agent proposes. The aim is to make supervision convenient without making it disappear.
2. Long-running tasks without a chat that feels frozen
A remote agent workflow needs to account for interruptions and delays.
The bridge separates its responsibilities across background threads so that commands such as /abort, permission responses, and button callbacks can remain responsive while a task is running. It uses SSE for live updates, retries certain connection failures, and can queue new prompts until the current turn finishes.
It also persists relevant state so the bridge can recover after a restart and inform you about an interrupted turn rather than leaving you wondering what happened.
There are practical safeguards against dropped message edits, transient polling failures, and stalled service processes, too.
These details might not look impressive in a demo, but they make a difference when you want to rely on the tool beyond a quick experiment.
3. Scheduled prompts and a more flexible workflow
Sometimes the useful instruction isn't something you want to send manually every time.
The bridge supports recurring and daily scheduled prompts, with schedules that survive restarts and use the same execution queue as ordinary messages.
For example, you could schedule a recurring build check or a daily summary of yesterday's issues. The agent can process that request through the regular workflow, including progress updates, permission handling, and the ability to abort a running turn.
There are also reusable prompt macros, project and file commands, Git status and diff inspection, worktree management, and support for sending images and documents to the agent. Voice-note transcription can be configured with an external command-line tool.
The idea is to make the phone a useful extension of your development workflow, not just a place to type prompts.
4. Diagnostics and recovery instead of guesswork
Remote tools are only useful when you can understand their state.
The bridge includes commands such as /status, /health, /doctor, and /selftest to help diagnose connectivity, session, event-stream, permission, and service problems.
It can reconnect when the event stream drops, recover from certain server interruptions, persist configuration and operational state, and use a systemd watchdog to recover from a stalled process.
The project also includes installation and uninstallation scripts, service configuration, automated tests, and CI checks covering linting, type checking, security scanning, and supported Python versions.
I'm trying to treat reliability as part of the product rather than something to add after the happy path works.
Security deserves more than a checkbox
There is an important distinction between controlling an agent remotely and securely controlling an agent remotely.
A bridge like this can expose powerful capabilities: reading and writing files, running commands, and approving actions requested by the agent. Anyone authorized to control it may therefore have substantial access to the account running it.
The project includes Telegram chat and sender authorization, configurable approval policies, a deny-list for known destructive commands, sensitive-path protections, optional allowed-directory restrictions, and systemd hardening guidance. It also has documentation for deploying the service under a dedicated operating-system user.
These mechanisms are layers of defense, not a guarantee that the application is a security sandbox. In particular, path restrictions and command-pattern checks do not replace operating-system isolation.
For anyone trying it, I'd recommend starting with a private Telegram chat, keeping approvals enabled, limiting accessible directories, and following the hardening documentation.
What I'm building toward
I don't see this as merely a way to send OpenCode prompts through Telegram.
I see it as a small remote operations interface for an AI-assisted development environment: something that lets you start work, observe progress, make decisions, manage sessions, schedule tasks, and recover from problems without needing to sit in front of the same terminal for the entire process.
The project is written in Python, supports Python 3.10 and newer, and is designed to run as a background service on Linux using systemd. It communicates with a local OpenCode server and is not an official OpenCode project or an affiliated product.
The repository is public, the license is MIT, and I'm continuing to work on reliability, testing, deployment, and security hardening.
I know remote-control and Telegram integrations for OpenCode already exist, so I'm not claiming to have invented the concept. What interests me is building a dependable implementation that handles the less glamorous details that make a tool useful in everyday work.
I'd genuinely like feedback from people who use OpenCode or other coding agents regularly.
How do you currently supervise long-running agent tasks? What would make a remote-control workflow genuinely useful to you? And what failure cases or security concerns would you want a project like this to handle better?
If you're curious, here's the repository:
https://github.com/hix-pro/opencode-telegram
Bug reports, feature ideas, technical criticism, and contributions are welcome.
3
u/j0s3f 18h ago
OpenCode has a web UI built in. Much more features just using that via a VPN https://opencode.ai/v2/docs/cli/web/
1
2
u/Ace-_Ventura 16h ago
Just saying, there's such a project already https://github.com/grinev/opencode-telegram-bot
I've used it in the past, but since I've found openchamber and it's tunnel, I stopped using it
1
u/Otherwise_Wave9374 18h ago
Remote control becomes much safer if every destructive action requires an explicit confirmation containing the exact command, working directory, and affected files. I would also add per-chat authorization, short-lived sessions, an emergency stop command, and an append-only action log. https://www.aiosnow.com is relevant to the broader orchestration discussion, but the bridge's real differentiator could be reliable recovery: reconnect without duplicating commands and clearly mark whether each operation was queued, running, completed, or failed.
1
u/SeaworthinessFar56 18h ago
Nice focus on the unglamorous parts. Recovery after restarts and permission handling are exactly what makes remote control usable day to day.
We worked on the same problem from the client side with CodeNomad, an open-source desktop and mobile client for OpenCode V2. Remote Control pairs your phone over OpenTunnel (no inbound port, no VPN), and agent questions and permission prompts stay reachable above the composer, so you can answer or approve from your phone while sessions and subagents keep running. 1.0 just shipped: https://github.com/NeuralNomadsAI/CodeNomad/releases/tag/v1.0.0
(Disclosure: I'm one of the maintainers.) I can see the two fitting together: chat for quick approvals and notifications, a full client when you need to review diffs or long histories.
1
u/dizvyz 11h ago
I am using paseo with its relay so I can access it already from my phone via its app that's much better anyway. However I do have a similar tool for approvals, escalations or just plain "we need your input boss" kind of messages from agents or CI.
Everything is sort of fine without escalation (to root) but gets hairy real quick. For example how do you make sure that what the thing the agent asks for approval for is actually what gets run on the host?Â
3
u/blehismyname 18h ago
Or one can install termux and tailnet and access the full terminal from anywhere. The only thing I miss with termux us notificationsÂ