Engineering Notes
Tooling · March 24, 2026

AI, the UI Anywhere

I have been vibe coding for a while now. Most of it works well — until you hit the part where you are just sitting in front of the terminal, waiting for the agent to finish, so you can type "okay, now do the next story." Very little input for a lot of waiting. So I built two Telegram bridges — TelePi and TeleCodex — to steer my coding agents from my phone. Turns out it was not that hard, and the ergonomics are better than anything else available.

Tooling AI Open Source

The problem: vibe coding has a dead-air problem

Here is the pattern. You give your coding agent a story. It reads files, runs commands, edits code. Maybe three to ten minutes of work. During that time you are sitting in front of your terminal watching it go. When it finishes, you say something like "okay, looks good — now do the next story." That is maybe ten words of input for minutes of wait time.

This is not a complaint about agent speed. The models are fast enough. The issue is that the interaction pattern ties you to your desk for what is essentially a supervisory role. You are not pair programming. You are approving and dispatching. And you do not need a full IDE for that.

I realized I wanted to steer from my phone. Not write architecture documents on a phone — that would be miserable. But "continue with story 3", "switch to the other project", "abort, that approach is wrong" — that kind of lightweight direction. The input is short. The output is streamable. Telegram is already open on my phone.

"You are not pair programming. You are approving and dispatching. And you do not need a full IDE for that."

Two bridges, two SDKs

I use two coding agents: Pi and OpenAI Codex. Both have TypeScript SDKs. Both expose session management, streaming events, and model configuration through public APIs. So I built a Telegram bridge for each.

TelePi wraps Pi's AgentSession SDK. Pi stores sessions as JSONL files, which means hand-off between CLI and Telegram is lossless — whoever opens the session file gets the full history. TelePi gives you cross-workspace session switching, model selection, voice transcription, and a clipboard-ready /handback command to resume in your terminal.

TeleCodex wraps the @openai/codex-sdk. Codex uses SQLite for thread storage and spawns a sandboxed subprocess for tool execution. TeleCodex adds per-context sessions (every Telegram chat or forum topic gets its own independent Codex thread), file exchange (send documents in, get generated files back), and Telegram-native authentication via device auth flow.

2
Agent bridges
17
Slash commands (TeleCodex)
180+
Tests across both projects

"How hard can it be?"

Genuinely, not that hard. Both SDKs are well designed. Pi gives you session.subscribe() with typed events for text deltas, tool execution, and agent completion. Codex gives you an async generator of ThreadEvent objects — thread starts, turn completions, item updates for messages, commands, file changes, and more.

The mapping to Telegram is natural. Agent text becomes an in-place edited message (debounced to respect rate limits). Tool output becomes inline summaries or expandable details, depending on your verbosity setting. Slash commands map to session operations: /new, /sessions, /model, /abort. Inline keyboards handle session switching and workspace picking without typing.

The hardest part was not the SDK integration. It was the Telegram formatting — converting Markdown with nested code blocks, HTML entities, and long messages into something that survives Telegram's HTML parse mode and 4096-character message limit. That took more edge-case handling than the actual agent wiring.

What makes this approach different

The core advantage is architectural. Both bridges treat Telegram as a thin client over an existing agent runtime. The session state lives on your machine — JSONL files for Pi, SQLite for Codex. Telegram is just one of the ways to read from and write to that state.

This gives you several things that closed-loop products cannot:

  • Bi-directional hand-off. Start a task in your terminal, hand it to Telegram when you leave your desk, hand it back when you return. Zero context lost. /handback gives you the exact resume command, clipboard-ready on macOS.
  • Model freedom. Both bridges let you switch models on the fly. Use Opus for planning, GPT-5.4 for execution, Sonnet for review. The agent does not care which Telegram message triggered the turn.
  • Per-topic isolation. TeleCodex maps each forum topic to its own Codex session. You can run three different projects in three topics of the same Telegram group, each with independent thread state and model settings.
  • File exchange. Send a document to TeleCodex and it stages it in the workspace. Codex processes it. Generated files come back as Telegram documents. No manual scp, no shared drives.
  • Voice input. Both bridges support voice messages via on-device parakeet-coreml or OpenAI Whisper. Speak your prompt, the bot transcribes and executes. Great for quick corrections when you are away from a keyboard.
  • Native Telegram UX. Reactions show processing state (👀 while working, 👍 when done). Inline keyboards handle session switching and model picking. Slash commands give you a full command palette. No custom app to install.

Security: Docker containers for isolation

Running a coding agent that can execute shell commands and edit files is inherently sensitive. Both projects ship Docker configurations with non-root containers and granular volume mounts. The recommended setup:

  • Mount only the workspace directory — not your home directory
  • Use workspace-write sandbox mode (Codex's default) to restrict file access to the project
  • Set TELEGRAM_ALLOWED_USER_IDS to restrict the bot to your Telegram account
  • Mount ~/.codex or ~/.pi read-only for auth state

This is not bulletproof security. You are still giving an LLM the ability to execute code on your machine. But the Docker boundary means a compromised session cannot escape the workspace, and the user allowlist means only you can trigger execution.

When to use it — and when not to

I would not use TelePi or TeleCodex to set up a new project from scratch. Architecture decisions, initial file structure, complex debugging — those deserve a full terminal with proper scroll-back and file browsing. The phone is the wrong tool for that.

But for everything after the initial setup? It is surprisingly good. "Implement story 4." "Run the tests." "Switch to the other project and check the build." "Abort — wrong approach, try it this way instead." These are all ten-word instructions that do not need a 27-inch monitor.

The pattern I have settled into: do the architecture pass and first story from the terminal. Hand off to Telegram. Steer from the couch, the kitchen, or a walk. When something needs careful attention, hand back to the CLI. The loop is fast because the hand-off is instant.

Both projects are open source

TelePi and TeleCodex are both MIT-licensed and available on GitHub. Each has a Docker setup, a comprehensive test suite, and a README that should get you running in under five minutes.

github.com/benedict2310/telecodex

All posts