Problem: Claude Code prompts cannot be answered from Telegram

[Filyus]

Sometimes Claude Code asks a question directly in the terminal, for example:

1. Yes
2. Yes, and don't ask again
3. No

Right now, this question cannot be answered from Telegram.

The reason is that this prompt is not sent through MCP. It is part of Claude Code’s own terminal UI and waits for input from stdin. Since hdcd-telegram runs as an MCP server inside Claude Code, it cannot control that terminal input.

So Telegram can send messages to Claude Code, but it cannot answer Claude Code’s own terminal prompts.

Idea 1: Add a runner mode

One possible solution is to add a new mode where hdcd starts and manages Claude Code itself.

Current architecture:

Claude Code → starts hdcd-telegram as MCP server

Possible new architecture:

hdcd-runner → starts Claude Code → connects it to Telegram

In this mode, hdcd would control the Claude Code process from the outside.

When Claude Code asks a question, hdcd-runner could send that question to Telegram with buttons. The user selects an answer in Telegram, and hdcd-runner sends the answer back to Claude Code.

This would make Telegram a real remote control interface for Claude Code.

This approach is probably the cleanest long-term solution, especially for router mode, because router mode already maps Telegram topics to different Claude Code sessions.

Idea 2: Use hooks for approval prompts

A smaller solution would be to use Claude Code hooks.

When Claude Code asks for permission, a hook could send the request to Telegram. Telegram would show buttons like:

Allow
Deny
Allow always

Then the hook would wait for the user’s answer and return the decision to Claude Code.

This would be easier to add than a full runner mode.

The downside is that it may be less reliable. For example, if the user does not answer in Telegram, the hook may block or time out. It would also need careful handling of pending requests, cancellations, and session routing.

Summary

The problem is not router mode itself. Router mode solves Telegram routing between multiple sessions.

The missing part is answering Claude Code’s own terminal prompts from Telegram.

There are two possible directions:

1. Runner mode — hdcd starts and manages Claude Code, so it can handle interactive prompts properly.
2. Hook-based approval bridge — use hooks to forward permission prompts to Telegram and return the user’s choice.

Runner mode is cleaner long-term. Hooks are probably easier as a first step.

[Filyus]

For the first version of runner mode, I think the security model can stay mostly based on workspace boundaries.

The runner config could define a list of allowed workspace roots. A workspace root is a directory where Claude Code sessions are allowed to run, for example a folder that contains all user projects.

From Telegram, the user could:

1. Start Claude Code in an existing project under an allowed workspace root.
2. Create a new project folder under an allowed workspace root.
3. Continue or stop an existing Claude Code session attached to a Telegram topic.
4. Answer Claude Code permission prompts from Telegram.

The important boundary is that the runner should not start Claude Code in arbitrary filesystem locations. It should only work inside configured workspace roots.

Actions inside a Claude Code session, such as git clone, installs, file edits, or shell commands, can stay under Claude Code’s own permission system. The runner only needs to decide where sessions can be created or started, and how those sessions are connected to Telegram topics.

[Filyus]

I am currently working on an alternative solution using hooks and editable Telegram messages. If successful, I will create a very large PR.