ductor - Messenger Control Layer for Coding CLIs

ductor puts your coding agent in a chat app. Its own description: “Claude Code, Codex CLI, Gemini CLI, Antigravity CLI, and Grok Build as your coding assistant — on Telegram, Matrix, and Slack.” The mechanism is deliberately unclever, and the README is proud of it: “Uses only official CLIs. Nothing spoofed, nothing proxied.”

It “runs on your machine and sends simple console commands as if you were typing them yourself,” which is why your existing subscriptions work — “No API proxying, no SDK patching, no spoofed headers. Just the official CLIs, executed as subprocesses.” State is plain JSON and Markdown under ~/.ductor/. It is MIT licensed, Python 3.11+, installed with pipx install ductor.

That design means a message in a chat room runs a process on your computer. So the only question that really matters is who is allowed to send one.

Read the allowlist section before the feature list

ductor documents its access control carefully, and for Telegram it is what you would hope:

Chat type	Check
Private	`user_id ∈ allowed_user_ids`
Group	`group_id ∈ allowed_group_ids` AND `user_id ∈ allowed_user_ids`

Both must pass, at least one user ID is required, and groups default to [] — none. A bot added to an unlisted group “warns and auto-leaves.” All of it is hot-reloadable from config.json.

Then there is a nuance for Matrix that deserves to be read twice, quoted exactly:

“In non-DM rooms, when group_mention_only=true, the bot requires @mention/reply and bypasses allowed_users checks for those group messages.”

Room-level filtering still applies, so this is not an open door. But within an allowed Matrix room, that setting means anyone present can mention the bot and have it run your coding agent on your machine. That is a documented behaviour, not a flaw — and it is also the one configuration detail most likely to surprise someone who set allowed_users and assumed it was the boundary.

The practical rule: on Matrix, treat allowed_rooms as the real access control and keep those rooms as private as the machine ductor runs on.

One more permission to notice: on Telegram, the bot sees only /commands in groups unless you “make it a group admin or disable Privacy Mode via BotFather.” Full group functionality therefore requires granting the bot admin rights or switching off Telegram’s own protection. Worth a conscious decision rather than following the setup tip past it.

Where the project stands

The release history is specific, so here it is rather than a vague “actively maintained”. From PyPI, there are 45 releases, and the last five were 0.18.1 (13 June), 0.18.2 (15 June), 0.19.0 (12 July), 0.20.0 (22 July) and 0.20.1 on 23 July 2026.

The HEAD commit on main in our clone carries the same date, 23 July 2026 — so the repository and the package agree, and both have been quiet for roughly two and a half months after a run of fast releases.

That is neither a red flag nor a reassurance on its own. For a tool whose job is to shell out to five rapidly changing CLIs, it does mean the compatibility surface is moving while ductor is not. If claude, codex or gemini changes its flags or output format, a subprocess-driving bot is exactly what breaks. Check the issue tracker for your specific CLI before committing to it, and be prepared to pin the CLI versions you know work.

What you actually get

The interaction model is layered, and the README is unusually honest that you probably need only the first layer: “This single chat is all you need. Everything else below is optional.”

One private chat with the bot, where every message goes to the active CLI and responses stream back. /model opens an interactive provider and model picker.
Groups with topics, where each Telegram forum topic — or each Matrix room — is an isolated session with its own context.
Automation and sub-agents on top of that, in the same runtime.

The isolation-per-topic design is the genuinely good idea here. Keeping separate conversations for separate repositories is something people improvise badly with terminal tabs, and a chat client already has the UI for it.

Matrix users get one additional benefit: E2EE is supported via matrix-nio[e2e], so the channel carrying your source code discussions can be encrypted. Telegram bot chats are not end-to-end encrypted, which is worth knowing if the content of your prompts is sensitive.

How it compares, and who it is for

ductor is the right shape if you want to keep using the official CLIs with your existing subscription and reach them from your phone. If you want a purpose-built client rather than a chat bridge, Happy is the direct comparison and has moved further in that direction; if you want a desktop terminal rather than remote access, cmux is a different answer to a related problem.

The finding: ductor’s subprocess-and-plain-files design is the right one for subscription reuse, its Telegram allowlist is genuinely dual-checked, and the Matrix group_mention_only behaviour bypasses the user allowlist inside allowed rooms. Configure the room list as if it were a login, and verify your CLI versions still work before relying on a project whose last release was in July.