How to Control OpenCode Through a Telegram Bot: Screenshots, Voice, and Your Own Skill

Controlling OpenCode through a Telegram bot provides a remote interface for sending tasks to an AI agent and receiving messages from it, including screenshots. The author describes a custom skill that connects OpenCode with the bot: through Telegram, you can send additional instructions, request fixes, and send voice messages.

This setup can be useful for a developer when a task is being performed on a computer containing the project, while it is more convenient to monitor progress from a phone. The bot does not replace OpenCode; it serves as a communication channel with the running environment, where the agent has access to the project files. The specific implementation depends on the tools and settings used, so the listed features should not be considered built-in capabilities of every OpenCode instance.

Why Connect OpenCode to Telegram

Telegram lets you send the agent a clarification without returning to your work computer and receive a brief progress report. For example, if the result in a screenshot differs from what was expected, the user can ask to change a specific element instead of describing the entire project again.

A remote channel is especially convenient for lengthy tasks when it is important to see an intermediate result or adjust the direction of the work. Connecting a bot does not by itself guarantee that OpenCode will run continuously in the background or that the task will finish without user involvement. This depends on the settings of the launch environment and message processing.

What Features Does the Bot Need

The minimum setup includes receiving a command, passing it to the working environment, and sending the response back to Telegram. For visual tasks, screenshot delivery is added. In the version described by the author, the bot also accepts voice messages and instructions that clarify or correct an already assigned task.

• Task submission: the bot receives text and directs it to the associated OpenCode process.
• Result report: the user receives a response about completed actions or a problem.
• Screenshots: the bot sends an image so the user can assess the state of the interface or project.
• Feedback: the user clarifies what needs to be redone or added.
• Voice messages: the system recognizes speech and passes its content as a command.

This is a list of target features, not a ready-made technical specification. The presence of voice input, for example, does not by itself explain how the system converts speech to text. This component and its behavior need to be defined when designing a specific system.

Screenshots and Feedback

A screenshot shows only the state of the screen at the moment it was taken.

It does not confirm that the code built successfully, the tests passed, or the changes were saved in the required files. To verify the result, the bot can send a text report along with the image if this feature is provided by the implementation.

After receiving a screenshot, the user formulates a specific change: for example, asking to alter the position of an element, check an error, or continue working after the indicated step. The more clearly the command describes the expected change, the easier it is to assess whether the agent's response matches the request. If the screenshot does not show the necessary context, it is better to request an additional report than to draw conclusions from an incomplete image.

Text and Voice Commands

A text command is convenient when you need to specify exact file names, parameters, and a sequence of actions. A voice message is suitable for a brief clarification when typing is inconvenient. However, speech recognition can make mistakes in names, commands, and technical terms, so critical instructions should be checked before being sent to the agent.

To reduce ambiguity, separate the objective from the constraints. First state what needs to be changed, then specify which files or parts of the project must not be touched, and ask for a report of the actions performed. If the command involves deleting data, publishing, or changing settings, check the text before starting rather than relying solely on the recognized voice input.

How to Design Your Own Skill

In the concept described by the author, a skill is a set of instructions for a specialized task. It can be adapted for remote control of OpenCode by specifying how the bot accepts requests, what the agent should report to the user, when to send a screenshot, and which actions require separate confirmation. This is a design decision, not a universal description of OpenCode's internal workings.

Start with a recurring scenario rather than trying to describe every possible command. For example, define the sequence: accept the task, report that work has begun, perform a limited set of actions, show the result, and wait for instructions if a correction is needed. Also specify the response format: a brief status, a list of changed files, an error message, or a screenshot. Overly general wording such as “do everything necessary” makes control more difficult and does not define the boundaries of authority.

The instructions should define stop conditions. The agent should report insufficient context, unexpected errors, and actions outside the scope of the task rather than continuing based on guesswork. If the project needs additional tools, choose them for the specific task and check them separately. A single skill does not guarantee compatibility with every set of extensions.

Access Permissions and Project Protection

OpenCode can work with files in the selected project folder, so remote access through a bot requires careful configuration. Grant the process only the permissions necessary for the task, and do not send secrets, access keys, or the contents of configuration files through the bot unless necessary. Store the bot token and other credentials separately from the conversation and source code.

Limit the group of users who can send commands. Before starting, check how the implementation associates a message with its sender and project so that an accidental or unauthorized request cannot access the working folder. If the bot serves multiple projects, the project-selection rules must be explicit. Otherwise, a command could end up in the wrong context.

Do not connect unverified skills or MCP servers without understanding their purpose. The author separately warns against installing tools that the user does not understand and recommends checking each component before use.

Testing on a Safe Task

Perform the first run on a test project or a copy of the files. Ask it to make a small change, receive a report and screenshot, then send a clarification and check that the bot passed it to the correct context. Separately verify that the system reports errors correctly and does not continue a dangerous action without clear confirmation.

Check the final result using more than just the screenshot. Open the changed files, verify the result using the project's usual tools, and make sure the test task did not affect unrelated data. This check helps reveal errors in command routing, voice recognition, and permission management before the setup begins working with an important project.

Ready-Made Skill or Your Own

A ready-made skill is convenient if it solves the same problem and its instructions are clear. A custom version is justified when you need a specific interaction sequence with the bot, rules for sending screenshots, or restrictions for a particular project. The author suggests three options: write a skill for your own work, find a suitable ready-made version, or ask a neural network to suggest tools and explain their purpose.

Treat a neural network's recommendation as a starting point, not as confirmation of safety or compatibility. Check what actions each component performs, what data it receives, and how to disable it. Do not install a large set of tools “just in case”: choose only what is needed for the described scenario and test each component separately.

Frequently Asked Questions About Controlling OpenCode Through Telegram

Can OpenCode Be Controlled by Voice Alone?

The author describes support for voice messages in a custom solution, but voice input is not available in every configuration. Audio reception and recognition must be configured separately, and important commands should be checked before execution.

Why Send a Screenshot If the Bot Already Sends a Text Response?

Text reports on actions, while a screenshot shows the visible part of the result. Neither format alone replaces checking the project's files and tests.

Do I Need to Write the Skill Myself?

No, a custom version is not always necessary. First, check a suitable ready-made skill and its instructions. If they do not cover the required process or constraints, describe your own scenario separately.