What happened
OpenClaw's commit adds a Telegram widget presenter and related handling to its Telegram integration. The feature uses Telegram message widgets, which the documentation describes as small interactive cards inside a private chat with a bot. The implementation supports Telegram Bot API 10.4's widget_query update, even though the grammY types used by the project stop at Bot API 10.3. The commit updates documentation and tests alongside the integration code.
Widgets are opt-in. Builders enable them with channels.telegram.widgets: true; the setting can also be applied per account through channels.telegram.accounts.<id>.widgets. The default is off for client compatibility: older Telegram clients cannot render widgets. OpenClaw's documentation says /status shows whether widgets are enabled. Groups, channels, and direct-message topics continue to use normal widget surfaces. When widgets are off, show_widget behaves as it did before, and taps on earlier widgets are dropped.
A widget runs in Telegram's sandbox and cannot use network access, CDNs, libraries, or remote images. OpenClaw says agents can draw charts with inline SVG or canvas and include images as data: URLs. The limits are 32 KB of HTML and 4 KB after compression. Widgets have no text inputs; they use buttons instead.
Before sending, OpenClaw runs a trial in QuickJS with a stand-in DOM, timers, and a tap on every enabled button. Script errors, endless loops, removed elements, unsupported CSS, network use, element or CSS-rule limits, and request() calls outside a tap are sent back to the agent for correction; the widget is withheld until those checks pass. Some findings are advisory rather than blocking: for example, more than 16 translucent or shadowed elements, or undefined or NaN on screen, are passed to the agent as notes while the widget is still sent. Web APIs the trial does not model, such as URL, result in widgets being sent unchecked.
When a user taps a button, TelegramWidget.request(data) sends a widget_request to the agent and the tap is acknowledged immediately. The agent can update the tapped widget in place by calling show_widget with only new state, limited to 1,024 bytes. New widget code creates a new message, as does a typed message. Widget code cannot send / or ! commands; each widget can make at most 10 requests per minute, and identical request text reaches the agent no more than once per minute.
What the archive adds
New Runtime's earlier coverage described Telegram's widget-sandbox framework for creating and testing HTML widgets embedded in messages (November 7, 2026). This is a new fact on a known story: OpenClaw now integrates Telegram's widget surface into an agent workflow, with its own opt-in behavior and preflight checks.
Trend signal
This supports agent-ready software exposes capabilities: OpenClaw exposes a bounded capability for an agent to present an interactive card and process button requests, rather than treating the chat as text-only. The feature is still constrained by platform compatibility and explicit limits.
Why now
OpenClaw's documentation identifies Telegram Bot API 10.4 as the version that supports message widgets. This commit adds the corresponding integration and handles the widget_query update despite the project's older grammY type definitions.
Why it matters
A message widget can make an agent's answer usable without asking someone to parse prose and type a follow-up command. A chart, choice, or compact status panel can instead present a bounded set of interactions within the conversation. That could be useful for agents returning operational summaries or asking a person to choose among a few next steps.
The implementation also shows the cost of that interface: developers must manage client compatibility, constrained HTML, no network access, and a request-based interaction model. The pre-send trial catches several classes of errors, but it does not fully model web APIs such as URL; passing the trial is therefore not proof that every client will render every widget correctly. Teams should treat widgets as an optional interaction layer and retain a useful text response or fallback.
Limits and uncertainty
The commit documents limits and validation behavior, but it does not establish how often the trial run catches failures in real use or how consistently supported Telegram clients render widgets. OpenClaw explicitly notes that some web APIs are not modeled, so widgets using them can be sent unchecked. The commit also does not report adoption, reliability measurements, or user outcomes. Compatibility should be tested against the clients a bot's users actually use.
Skill to build now
If your OpenClaw bot returns a chart or asks users to choose among a few actions, prototype that result as a button-driven widget with no external assets. Keep it within the documented size limits, enable the feature only for compatible clients, and preserve a plain-text fallback. Test the tap-to-state update path as well as initial rendering.
Reader takeaway
OpenClaw brings Telegram's interactive message widgets into agent conversations, but the capability is deliberately narrow: private-chat cards, buttons instead of text fields, no network access, and compatibility-sensitive opt-in. It is a useful additional output surface, not a replacement for ordinary chat messages.