Telegram Bridges for Gemini CLI and Codex After Hitting Claude Code Limits

Claude Code usage limits forced me into an annoying realization: the thing I had become dependent on was not just the model. It was the workflow.

Once you get used to sending work to an agent from your phone, waiting for the reply, then sending the next step while you are away from your desk, normal terminal-only usage starts to feel primitive. So instead of waiting for official remote workflows to improve, I built a small Telegram bridge for two tools I already had locally:

• Gemini CLI
• Codex

This is not a polished platform. It is a local-first workaround. But it brought back the async loop I actually cared about.

The problem was not "which model"

Claude Code Channels changed how I work on side projects.

I could be in a cafe, walking outside, or traveling, and still move a repo forward from Telegram. That changes the whole shape of development. You stop thinking "I need to sit down and code now" and start thinking "I can send the next instruction right now and review the result later."

When I hit usage limits, I did not really want a different chatbot. I wanted that loop back.

Gemini CLI and Codex were already on my machine. What they did not have was the same remote, async, mobile-friendly interaction model.

So I built a bridge.

The architecture is intentionally boring

The whole thing is small:

• a local Node.js process polls the Telegram Bot API
• it accepts prompts from a specific chat
• it runs Gemini CLI or Codex against a local repository
• it sends stdout and stderr back to Telegram

That is basically it.

I ended up with two integrations:

• codex-telegram-integration
• gemini-telegram-integration_v2

I published the repo here:

github.com/0xkaz/codex-gemini-telegram-bridge

I like this design because it stays easy to inspect. No hosted backend. No extra control plane. No mystery service between Telegram and the machine where the repo already lives.

For this kind of tool, that matters. The simpler the chain, the easier it is to trust and debug.

Session continuity is what makes it useful

The first version could have been a dumb "Telegram to shell" relay. That would have been enough for a quick demo. It would not have been enough for actual use.

The real requirement was session continuity.

If I send a follow-up prompt, I do not want the assistant to forget what happened two messages ago. I want it to continue the current session, keep recent context, and move forward from there. Without that, the UX collapses into repetitive setup messages and wasted tokens.

That turned out to be the difference between "interesting hack" and "something I actually keep using."

I also made plain non-command messages behave like prompts by default. I did not want to type slash commands every single time. That small choice made the Telegram chat feel much closer to a real agent interface.

Telegram formatting matters more than I expected

Raw CLI output looks much worse in chat than it does in a terminal.

That sounds trivial, but it is not. If replies wrap badly, file links are unreadable, or errors dump full stack traces into Telegram, the workflow becomes annoying fast.

So I added a few quality-of-life features:

• typing indicators while the command is running
• session commands like /sessions, /resume, and /reset-session
• cleaner error summaries
• cleanup for markdown-style file links

None of this is glamorous. All of it matters.

Gemini quota errors exposed a product problem

One of the most useful failures happened while testing the Gemini side.

I hit quota exhaustion. That exposed a bad assumption in the bridge: terminal-grade errors are acceptable in a shell, but often terrible in chat. Dumping a raw quota stack trace into Telegram is not useful. It is just noise.

So I added error summarization instead of forwarding everything blindly.

That changed how I thought about the bridge. Once a CLI tool starts replying inside Telegram, the output itself becomes part of the UX. A raw stack trace is acceptable in a terminal. In chat, it just feels broken.

What this bridge restores

It does not reproduce Claude Code Channels exactly.

What it does restore is the part I cared about most:

• sending prompts from my phone
• letting the machine at home do the work
• reading a useful reply later
• continuing in the same thread without resetting context

For side projects, that is enough.

What I would warn people about

• This is a stopgap, not a finished platform.
• You should strictly limit which Telegram chat is allowed to talk to it.
• Destructive actions like commit, push, or deploy need extra care.
• Model quotas still apply, especially on Gemini.

I would still take this over being locked back into terminal-only usage.

Why I think this category matters

I do think Gemini CLI and Codex will eventually get better official remote workflows. That feels inevitable.

But "eventually" is not very useful when the workflow break is happening right now.

This bridge is exactly the kind of engineering I like: not the final version, not especially elegant, but good enough to restore a missing capability immediately.

If you got used to Claude Code Channels and want something similar for Gemini CLI or Codex today, a local-first Telegram bridge is a surprisingly practical answer.