If you want Codex in Telegram, the hard part is not sending one clever prompt from your phone. The hard part is everything around it: how you re-pair auth when a token expires, how you redirect a long coding run without waiting for it to finish, and what happens when Telegram accepts your preview messages but drops the final reply.

That is why the most practical workflow upgrade in OpenClaw v2026.7.1-beta.1 is not just “Telegram support.” It is a specific Codex Telegram loop:

  • /login codex can start device-code pairing from a private Telegram chat
  • /steer, /tell, and /queue can reach an active Codex run through Telegram’s control lane
  • final replies can recover from several Telegram delivery failures instead of silently disappearing after the preview

If you already know what OpenClaw is and how OpenClaw works, this release matters because it makes Telegram a more credible control surface for real coding sessions rather than a thin notification layer.

In this guide

Why Codex in Telegram used to break at the worst moments

A lot of “AI coding in chat” demos stop too early. They show a bot replying to a one-shot question. They do not show what happens after twenty minutes of tool calls, an auth refresh failure, or a Telegram API rejection on the final handoff.

In practice, a Codex Telegram bot has three fragile points:

  1. Login recovery — when OpenAI/Codex auth expires, a remote or channel-only operator needs a way to recover without SSH-ing into the Gateway.
  2. Mid-run control — when a Codex turn is already busy, you still need to say “skip that file,” “focus on the failing test,” or “queue this follow-up.”
  3. Durable delivery — if Telegram rejects the final message after previews already streamed, the user sees the worst possible outcome: visible activity followed by no final answer.

Those are not edge cases. They are the basic mechanics that decide whether Telegram is a serious coding surface or just a novelty wrapper around a better desktop workflow.

OpenClaw had already done earlier Telegram reliability work in our durable spool write-up and the group-chat rich replies release guide. The July beta extends that story in a more coding-specific direction: make Codex usable from Telegram when the session is already live and messy.

What changed in OpenClaw v2026.7.1-beta.1

The v2026.7.1-beta.1 release notes group the work under Telegram Codex workflows and call out three user-facing upgrades:

  • Telegram can start Codex pairing with /login
  • Telegram can steer active Codex runs
  • Telegram can recover final replies across transient API failures

That sounds small until you unpack it.

1) Telegram can initiate Codex pairing from chat

PR #98006 adds /login codex for OpenAI/Codex device-code pairing from channel surfaces. The important detail is not just that the command exists. It is that the flow is explicit, private-path only, and owner/admin gated.

The PR summary is clear about the design:

  • Telegram private chat can show the device URL and code
  • Telegram groups and topics do not emit the device code
  • owners are told to DM the bot instead
  • the gateway reuses the existing OpenAI/Codex device-code auth flow rather than inventing a Telegram-specific auth shortcut

That is the right boundary. A coding workflow needs remote recovery, but it should not spray auth prompts into shared rooms.

2) Telegram can steer active Codex turns without waiting behind the busy lane

PR #98126 fixes a subtler operational problem: Telegram /steer, /tell, and /queue commands now route through Telegram’s control lane, and Codex active-run lookup becomes much more reliable.

Why that matters: if the control message has to wait behind the same long-running chat lane it is trying to control, steering is fake. It exists in theory, but not at the moment you need it.

OpenClaw’s own steering queue docs explain the runtime model well. Steering does not interrupt a tool call in the middle. Instead, OpenClaw drains queued steering messages at the next model boundary so the next model call can absorb the new instruction. In Codex’s native path, OpenClaw batches queued prompts and sends them with turn/steer.

That gives you a practical mid-run control loop from Telegram:

  • a Codex run is already active
  • you send /steer focus only on the failing tests
  • Telegram control routing gets the command to the right active run
  • the next model decision sees the steering message without forcing a brand-new turn

If you want the broader mechanics, our /steer guide covers the queue behavior in more depth. The new Telegram-specific work matters because it makes that behavior reachable from an actual phone-first surface.

3) Final replies recover instead of dying after the preview

PR #98786 is the least glamorous part of the feature set and probably the most important.

It fixes Telegram’s durable send path so final replies can degrade and retry across several recoverable Telegram failures that the streaming preview path already tolerated. The PR calls out cases like:

  • invalid rich entities
  • captions whose HTML Telegram rejects
  • rejected quoted replies
  • group flood waits longer than the old retry budget

This matters because users judge reliability by the final visible state, not by the fact that a preview briefly appeared. If a Telegram coding bot streams progress, looks alive, and then loses the actual answer, the experience feels broken even if the runtime technically finished.

For a Codex Telegram integration, durable final delivery is part of the feature, not an implementation detail.

How /login codex works in Telegram

The cleanest mental model is: Telegram becomes the trigger, not the token store.

According to PR #98006, /login codex does four things:

  1. verifies the command is coming from an authorized owner/admin
  2. requires a private response path before revealing device-code details
  3. reuses OpenClaw’s existing OpenAI/Codex device-code auth flow
  4. persists the refreshed OpenAI auth profile after the browser pairing succeeds

That design solves a real operational gap. Before this, a remote operator whose Codex/OpenAI OAuth had expired often had a terminal-only recovery path. Now the gateway can respond to a hard auth failure with guidance to use /login codex from private chat or the Web UI.

In plain English: if your Codex session is failing because the login expired, you no longer have to be physically at the machine running the Gateway.

That is especially useful if you set OpenClaw up the way many people actually do: one long-lived Gateway, then multiple control surfaces layered on top. If you are still earlier in that journey, Connect OpenClaw to Your Phone is the right setup primer.

How Telegram steering reaches an active Codex run

There are two separate ideas here: runtime steering and Telegram command routing.

The runtime side comes from OpenClaw’s queue system:

  • steering messages are applied at the next model boundary
  • they do not interrupt a tool call already in flight
  • Codex-native runs receive queued guidance through turn/steer

The Telegram side comes from PR #98126: /steer, /tell, and /queue no longer sit behind the same busy lane as the long-running Codex chat lane, and active-run lookup can recover through the session key, session file, sibling DM lanes, and legacy fallback paths.

That sounds internal, but the user-facing effect is simple: Telegram control commands arrive when they are still useful.

A few concrete cases:

Case 1: tighten a coding task without restarting it

You asked Codex to investigate a bug. Halfway through, you realize it is touching too much scope.

/steer only inspect the auth middleware and its tests; skip UI files

That is faster and cheaper than aborting the run and starting from scratch.

Case 2: add a follow-up while the run is still hot

Your teammate pings the group with one more requirement while Codex is already working.

/queue after this run, summarize only the fix and the rollout risk

Case 3: keep a phone-first coding loop alive

You are away from the terminal, but the active run still needs correction. Telegram becomes the control surface, not just the alert surface.

This is also where OpenClaw’s Telegram channel docs matter. The docs are explicit that one-owner bots should use durable numeric allowFrom IDs, explicit group allowlists, and private DM pairing rather than treating Telegram as a public bot surface. Good steering is only useful if the authorization boundary is sane.

Why final-reply recovery matters more than flashy previews

The easiest thing to demo is a streaming preview.

The harder and more important thing is the final answer arriving correctly after Telegram does something annoying.

PR #98786 closes a trust gap that a lot of chat-first coding systems leave unresolved: the preview path may look healthy, but the durable send path fails on a richer set of Telegram-specific errors.

OpenClaw now degrades or retries in cases where the final reply would previously die, including:

  • falling back from rich formatting to plain text when Telegram rejects the entity set
  • dropping to a plain caption when Telegram rejects the caption HTML
  • retrying without a native quote when the quote target is rejected
  • tolerating longer Telegram retry_after waits for flood control

That recovery work is not the headline keyword, but it is why the headline keyword is believable.

If you are evaluating “codex telegram bot” or “codex telegram integration” solutions, this is the real question to ask: when the channel misbehaves, do I lose the answer or just lose a bit of formatting?

How to set up a Codex Telegram workflow

The practical setup is simpler than it sounds.

1) Get Telegram running as a controlled channel

Start with the official Telegram docs. The shortest useful pattern is:

  • create the bot in BotFather
  • configure botToken
  • keep dmPolicy: "pairing" or move to allowlist for one-owner bots
  • put your numeric Telegram user ID in allowFrom
  • explicitly allow the groups you want under channels.telegram.groups

The docs also warn about a subtle point many people miss: DM pairing approval does not automatically grant group access. Group authorization still comes from explicit config.

2) Make sure Codex can actually run on the Gateway host

If you want Codex-native behavior, OpenClaw’s Codex harness docs and ACP agents docs help explain the difference between the native Codex path and explicit ACP fallback paths.

The practical takeaway is simpler: the Gateway host still needs the right provider auth and runtime setup. Telegram is the surface; the Gateway is still the machine doing the work.

3) Use /login codex from private chat when auth needs recovery

Do not treat /login codex as a public-room command. The release work is specifically designed to keep the code and verification URL on a private path.

4) Use steering for correction, not interruption

If the run is still productive but needs direction, use /steer. If the run is wrong and should die, interrupt it instead. Steering is for course correction, not for pretending a bad run is still salvageable.

5) Judge the workflow by the final state

A strong Telegram coding setup should pass this test:

  • pairing can be recovered remotely
  • an active run can be redirected from chat
  • the final answer still lands even when Telegram rejects the first delivery attempt

That is a better production checklist than “it answered one coding question from my phone.”

The bigger takeaway

The interesting part of this beta is not that OpenClaw can talk to Telegram or that Codex can run inside OpenClaw. Both of those were already directionally true.

The upgrade is that the control loop got tighter:

  • auth recovery no longer forces a terminal hop
  • steering no longer depends on a quiet chat lane
  • final replies no longer fail as easily after visible progress has already started

That makes Codex Telegram workflows feel less like a stunt and more like a usable operator surface for real coding sessions.

It also fits the broader OpenClaw pattern: the Gateway remains the durable layer, while chat surfaces become better ways to reach it. Telegram is just the channel in this release. The actual product improvement is that the channel can now carry more of the operational load.

FAQ

What is the main keyword this post targets?

The primary product-intent keyword is codex telegram. Closely related variants include codex telegram integration, codex telegram bot, and codex telegram mcp.

Can I really run Codex from Telegram without staying at a terminal?

Yes, with an important qualifier. Telegram becomes a control surface for pairing recovery, steering, and visible delivery, but the Gateway host still runs the Codex-backed session and must have the underlying auth and runtime setup.

Does /login codex expose a device code in group chats?

No. The Telegram pairing work is intentionally private-path only. Group or topic invocations tell the owner to DM the bot instead of emitting the verification code into a shared room.

Does Telegram steering interrupt a tool call immediately?

No. OpenClaw applies steering at the next model boundary, not in the middle of an already running tool call. That is what keeps tool results paired with the assistant message that requested them.

Why mention reply recovery in a coding workflow post?

Because a coding workflow is only as trustworthy as its final visible state. If a Telegram bot shows progress but loses the answer, the operator still has a broken workflow.

Is this in the stable OpenClaw web changelog yet?

Not at the time of this run. The public web changelog is still anchored to the latest stable release line, while this feature set is highlighted in v2026.7.1-beta.1.

Sources