#Multi-channel Synchronization Issue

1 messages · Page 1 of 1 (latest)

blissful belfry
#

If a message is sent in the TUI, the following appears in the dashboard:
Conversation info (untrusted metadata):

{
“conversation_label”: “openclaw-tui”
}
[Sat 2026-02-14 11:35 GMT-5] Hello

And I respond normally, but nothing appears in Telegram, as if I hadn't written anything.

If I write in Telegram, the chat appears normally, both in Tui and in the dashboard.

If I write in the dashboard, it appears normally, and it also appears in Tui, but it doesn't appear in Telegram.

mystic jayBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

glad kindleBOT
#

That conversation_label: "openclaw-tui" line is the key: it means the message originated from the TUI (a WebChat-like client), not from Telegram.

OpenClaw’s routing is deterministic: it replies back to the same surface/channel the message came from. So:

  • Telegram → replies go to Telegram (and you’ll also see them in TUI/Dashboard because they share the gateway session transcript)
  • TUI/Dashboard (WebChat) → replies go to TUI/Dashboard, not Telegram

This is expected behavior, not a Telegram “send failed” bug.

Docs:

What you can do instead

Option A (recommended): Use Telegram as the “sending” client

#

Keep using Telegram to send messages if you want the conversation to appear there, and use TUI/Dashboard mainly as an “operator console” to view/debug.

Option B: Send to Telegram explicitly (manual push)

If you want to push a message into Telegram from outside Telegram, use the CLI:

openclaw message send --channel telegram --target <chatId-or-@username> --message "..."

(You’ll need the numeric chat id for groups; easiest way is to look at openclaw logs --follow and grab chat.id.)

Option C (TUI-specific): double-check you didn’t just want “delivery”

In the TUI, delivery to providers can be toggled; run:

  • /status (check what it says for deliver)
  • /deliver on
#

This mainly matters when you’re handling provider messages while the TUI is connected.

Quick clarifier

When you say “I respond normally in the dashboard” — do you mean:

  1. you type in the dashboard chat input (WebChat), or
  2. you expect the bot’s reply to a Telegram message to be delivered, but it’s only showing up in UI/TUI?

If you paste:

  • openclaw --version
  • and the output of /status from the TUI

…I can tell which case you’re in immediately.

blissful belfry
#

I understand, what you say makes sense, since they are separate channels, the behavior is also separate. Please check, because previously, regardless of the channel through which the message was sent, it was reflected in all three, whether sent from Telegram, the dashboard, or Tui, the message always appeared in all of them. I'm not sure if it's due to some configuration or a change in the 2026.2.12 update, but I wanted to check because it's different from what I had seen before.

glad kindleBOT
#

You’re remembering a real-looking behavior, but it’s almost certainly “delivery was enabled + the session had a Telegram reply target”, not “all channels are always mirrored.”

Two different things get conflated:

  1. Transcript visibility (Gateway session history)
  • The Control UI and TUI always show the gateway-backed transcript for the session you’re looking at, so they “reflect” a lot of activity.
  1. Outbound delivery to Telegram (actually sending a Telegram message)
  • A message you type in TUI / Control UI is not a Telegram inbound message, so there is no automatic rule that it must send to Telegram.
  • In the TUI, this is explicitly controlled by delivery, which is off by default: https://docs.openclaw.ai/web/tui#sending--delivery

So if it “used to show up in Telegram”, that usually means one of:

  • You had /deliver on in the TUI (or started with openclaw tui --deliver)
  • And you were on the same session that had recently been driven by Telegram, so the gateway had a natural Telegram “reply target” for that session.

What to check (fast)

In the TUI:

#
  • Run: /status and confirm what it says for deliver
  • Then: /deliver on
  • Make sure you’re on the same session as the Telegram chat (DMs typically collapse to the agent’s main session; groups/threads don’t).

If after /deliver on it still doesn’t send to Telegram, then it’s a regression/bug and logs will show why.

What I need to confirm if it’s a 2026.2.12 change/regression

Please paste:

  • openclaw --version
  • the TUI /status output
  • and (best signal) a short log excerpt from when you send one message from TUI:
    openclaw logs --follow

(You can stop it after the attempt; tokens are redacted in the CLI status/log helpers.)

Also note: the Control UI chat does not have the same “deliver” toggle documented like the TUI; for “send something to Telegram no matter what”, the reliable path is explicit:

#

If you want, describe your exact “old behavior” steps (e.g., “send in Telegram → then type in TUI and it would post back to Telegram”), and I’ll tell you the exact minimal reproduction to validate whether 2026.2.12 changed anything.

blissful belfry
#

openclaw tui - ws://127.0.0.1:18789 - agent main - session main

session agent:main:main

Gateway status

Link channel: unknown

Heartbeat: 30m (main)

Session store: /home/doc/.openclaw/agents/main/sessions/sessions.json

Default model: gemini-2.5-flash-lite (1.0m ctx)

Active sessions: 1

Recent sessions:

  • agent:main:main [direct] | just now | model gemini-2.5-flash-lite | tokens 0/1.0m (1.0m left, 0%)
glad kindleBOT
#

That status output is super helpful — the important bit is:

  • Session: agent:main:main
  • Link channel: unknown

A couple clarifications that explain the “it used to sync everywhere” feeling:

1) Control UI chat ≠ Telegram

The Control UI chat is effectively WebChat (chat.send over the gateway WS). By design, replies route back to WebChat, not Telegram. So “type in dashboard → see it in Telegram” is not a guaranteed behavior (and isn’t documented as one).
Docs: https://docs.openclaw.ai/web/webchat

What is guaranteed is: Telegram traffic will show up in the Control UI/TUI transcript (because they’re looking at the gateway’s session log). That can look like “sync”, but it’s mostly “shared transcript,” not “mirrored delivery.”

2) TUI can deliver — but only if the session has a delivery target

TUI has a deliver toggle, but the gateway still needs to know where to deliver to (Telegram chat id / etc). That’s stored as session metadata (things like lastChannel / lastTo / deliveryContext).

If that metadata isn’t set (or you’re in the “wrong” session key), delivery won’t happen.

#

What I’d do next (quick, deterministic)

  1. In Telegram, send one message to the bot in the chat you care about.

  2. On the gateway host, run:

    openclaw sessions --json

    Then look for either:

    • a session key like agent:main:main that has lastChannel: "telegram" / lastTo: ..., or
    • a separate session key like agent:main:telegram:dm:<id> (meaning your DMs aren’t collapsing to main)

  3. In the TUI:

    • make sure you’re on the same session key that Telegram is actually using
    • then run: /deliver on
    • send a test message

If you paste the openclaw sessions --json output (you can redact IDs if you want, but keep the shape of the keys + whether lastChannel/lastTo exists), I can tell you exactly why TUI delivery isn’t reaching Telegram.

#

3) If you want “TUI as a Telegram console”, consider changing DM scoping

Right now you’re on agent:main:main, which is the collapsed DM bucket (session.dmScope: "main"). If you switch to per-channel DM sessions, you get explicit Telegram session keys, which makes “send from TUI to that Telegram chat” much less ambiguous:

{
  session: { dmScope: "per-channel-peer" }
}

Docs: https://docs.openclaw.ai/concepts/session#use-sessiondmscope-to-control-how-direct-messages-are-grouped

This will change how your DM context is grouped (often a good idea anyway).

If after /deliver on + confirming the right session key, it still doesn’t deliver, then it’s likely a bug/regression — and the gateway logs right after the TUI send will show the exact skip reason.

blissful belfry
#

openclaw sessions --json
{
"path": "/home/doc/.openclaw/agents/main/sessions/sessions.json",
"count": 1,
"activeMinutes": null,
"sessions": [
{
"key": "agent:main:main",
"kind": "direct",
"updatedAt": 1771090038278,
"ageMs": 12204,
"sessionId": "3930566c-7746-44d6-81d8-2cd1273d3d48",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 14197,
"outputTokens": 231,
"totalTokens": 28143,
"model": "gemini-2.5-flash-lite",
"contextTokens": 1048576
}
]
}

I put /deliver on in the telegram and it replied: Understood. I have enabled message delivery in this conversation. From now on, you will receive messages and notifications from OpenClaw here.

And if I send a message in Telegram, both in the UI and in the TUI, I see the message, but with metadata:
Conversation info (untrusted metadata):

{
“conversation_label”: “TheDoctor (@TheDoctor_14) id:1855515416”
}

I thought it had been fixed. If I send a message in the TUI in the UI, it appears, but with the metadata:
Conversation info (untrusted metadata):

{
“conversation_label”: “openclaw-tui”
}

But in none of these cases does it appear in Telegram; it only appears if I send it from Telegram.

glad kindleBOT
#

Yep — with the data you posted, what you’re seeing is consistent, and it’s not your config.

What’s actually happening

1) Control UI chat will never post to Telegram

The Control UI uses the Gateway WS method chat.send, and it hardcodes deliver: false (so it’s “WebChat-only”). That’s why anything you type in the dashboard shows up in dashboard + TUI (shared transcript) but never in Telegram.

So: Dashboard → Telegram mirroring is not a supported behavior in current builds.

2) TUI “/deliver on” doesn’t help (right now) because chat.send isn’t delivering

The TUI also uses chat.send. Even though the TUI has a deliver toggle, the gateway-side chat.send handler does not currently route outbound replies to Telegram the way the normal Telegram inbound path does.

Net result: TUI sends stay internal (TUI/UI transcript only), and Telegram only sees messages that originated from Telegram.

3) The “Conversation info (untrusted metadata)” block is normal

That’s just OpenClaw’s safety wrapper that gets prepended to the prompt body for the model, and since UI/TUI show the gateway transcript, you see it there. It doesn’t mean Telegram delivery is “almost working” — it’s just the internal envelope.

#

Workarounds (today)

A) If you want something to appear in Telegram, send from Telegram

That’s the only path that will always land back in Telegram.

B) If you want to type locally but still post to Telegram: use openclaw agent --deliver

This uses the Gateway agent method (which does support explicit delivery):

openclaw agent --agent main \
  --message "Hello from terminal" \
  --deliver --reply-channel telegram --reply-to 1855515416

1855515416 matches the Telegram id you’re seeing in the conversation label.

#

(If you just want to send text without running the model, use openclaw message send --channel telegram --target 1855515416 --message "...".)

Next step (so we can get it fixed properly)

This looks like a real “TUI deliver doesn’t deliver” mismatch. If you can, please post your:

  • openclaw --version

…and then file a GitHub issue with your exact repro steps + the outputs you already pasted:
https://github.com/openclaw/openclaw/issues

If you tell me your version, I can also tell you whether it’s worth trying 2026.2.13+ first (in case it was fixed right after 2026.2.12).

blissful belfry
glad kindleBOT
#

No — you’ve got a couple of workarounds you can apply yourself right now.

What you can’t do yourself (without a code change / update) is: “type in Control UI / TUI and have it automatically mirror into Telegram like before.” That part looks like either (a) never-guaranteed behavior or (b) a regression in how chat.send + “deliver” is handled.

Practical workarounds (no GitHub issue required)

1) If you just want to push text into Telegram (no model run)

openclaw message send --channel telegram --target 1855515416 --message "Hello from my terminal"

2) If you want to type locally but still have OpenClaw run the model and deliver to Telegram

openclaw agent --agent main \
  --message "Write my reply here" \
  --deliver --reply-channel telegram --reply-to 1855515416
#

That’s basically “use the CLI as your console” while Telegram remains the delivery surface.

When to open an issue

If your goal is specifically:

  • “/deliver on in the TUI should make TUI-sent messages show up in Telegram”

…then yeah, that’s bug/behavior-mismatch territory, and a GitHub issue is the right way to get it fixed.

Correct link (plural): https://github.com/openclaw/openclaw/issues

If you do file it, include:

  • openclaw --version
  • exact repro steps (TUI send vs Telegram send)
  • and ideally a short openclaw logs --follow snippet around a TUI send attempt (tokens redacted automatically in the usual helpers).
blissful belfry
#

openclaw message send \

--channel telegram \

--target 1855515416 \

--message "Hello from my terminal"
error: required option '-t, --target <dest>' not specified
--channel: command not found
--target: command not found
--message: command not found
openclaw agent --agent main \

--message "Write my reply here" \

--deliver \

--reply-channel telegram \

--reply-to 1855515416

error: required option '-m, --message <text>' not specified
--message: command not found
--deliver: command not found
--reply-channel: command not found
--reply-to: command not found

glad kindleBOT
#

Those errors are just your shell telling you the line continuation didn’t work.

In bash/zsh, a \ only continues the command if it is the very last character on the line (no trailing spaces), and you can’t have blank lines in the middle. In your paste, the blank lines break the command, so --channel, --target, etc. get executed as separate commands.

Use one line (easiest):

openclaw message send --channel telegram --target 1855515416 --message "Hello from my terminal"

And for an agent run + deliver to Telegram:

openclaw agent --agent main --message "Write my reply here" --deliver --reply-channel telegram --reply-to 1855515416

If you really want multi-line, it must look like this (no empty lines, and \ at end-of-line):

# 
openclaw message send \
  --channel telegram \
  --target 1855515416 \
  --message "Hello from my terminal"

If that still doesn’t send to Telegram, paste the output of:

openclaw message send --channel telegram --target 1855515416 --message "ping" --verbose
blissful belfry
#

openclaw message send --channel telegram --target 1855515416 --message "Hello from my terminal"

🦞 OpenClaw 2026.2.12 (f9e444d) — I'll butter your workflow like a lobster roll: messy, delicious, effective.

│
18:29:25 [telegram] autoSelectFamily=false (default-node22)
â—‡
âś… Sent via Telegram. Message ID: 411
openclaw agent --agent main --message "Write my reply here" --deliver --reply-channel telegram --reply-to 1855515416

🦞 OpenClaw 2026.2.12 (f9e444d) — Because the right answer is usually a script.

│
â—‡
¿Qué te gustaría escribir en tu respuesta?

The first command that was sent to Telegram was not visible in the UI, but the message appeared in Telegram. The second command appeared in all three: the UI, TUI, and Telegram.

glad kindleBOT
#

Nice — that result actually clarifies everything:

  • openclaw message send ... did send to Telegram (Message ID 411).
    It won’t necessarily show up in Control UI/TUI, because it’s a proactive send done via the CLI, not a chat.send run that appends into the gateway’s current session transcript. So it can appear “missing” in UI/TUI even though Telegram received it. (Telegram is the source of truth for that particular action.)

  • openclaw agent ... --deliver ... runs a real agent turn and then delivers the final reply to Telegram. That’s why it appeared in all three:

    • UI + TUI: because the agent run is recorded in the gateway session transcript
    • Telegram: because --deliver sent it out

So you do have a self-serve solution:

Recommended workflow if you want “type here, deliver to Telegram”

Use openclaw agent ... --deliver --reply-channel telegram --reply-to <chatId>.

Example:

# 
openclaw agent --agent main \
  --message "Draft a concise reply confirming the plan." \
  --deliver --reply-channel telegram --reply-to 1855515416

Why TUI/Control UI still won’t mirror into Telegram

TUI/Control UI chat uses chat.send, and that path is essentially “WebChat” (internal) and doesn’t reliably deliver outward to Telegram. That’s the behavior you originally hit.

If you want, I can help you turn this into a tiny shell alias/script so it feels like “TUI-to-Telegram” with one command.

And if this answers your question, please mark the solution in Discord so Answer Overflow indexes it (right‑click the solution message → Apps → ✅ Mark Solution).

blissful belfry
#

So, is there a way to add Telegram to chat.send so that it is in the internal WebChat (shared transcript)?

glad kindleBOT
#

Not via config today, no.

chat.send is the “WebChat/TUI/Control‑UI chat” path, and it’s treated as internal (Provider/OriginatingChannel = internal/webchat). In 2026.2.12 it doesn’t have a supported mechanism to auto-deliver to Telegram (and the Control UI even sends deliver: false on purpose).

So there isn’t a knob like “bind chat.send to Telegram” / “mirror chat.send to Telegram” that you can turn on.

What to use instead (keeps the shared transcript and posts to Telegram)

Use the agent path with delivery:

openclaw agent --agent main --message "..." --deliver --reply-channel telegram --reply-to 1855515416

That’s the closest equivalent to “chat.send + deliver to Telegram”, and it’s why you saw it show up in UI + TUI + Telegram.

If you want this inside the Control UI / TUI chat input

That’s feature/bug territory (basically: “make chat.send honor a delivery target”). For that, opening an issue/feature request is the right route:

#

https://github.com/openclaw/openclaw/issues

If you want, I can help you phrase the issue with the exact repro + expected behavior (very short: “TUI /deliver on doesn’t deliver to Telegram; openclaw agent --deliver does”).

blissful belfry
#

If you create an issue, but don't limit it to Telegram; include any medium, whether it be Telegram, WhatsApp, Discord, Slack, etc.

glad kindleBOT
#

I can’t create the GitHub issue for you (I don’t have the ability to file issues on your behalf), but I can give you a ready-to-paste issue that’s channel-agnostic (Telegram/WhatsApp/Discord/Slack/etc.) and describes the behavior clearly.

Here’s a draft you can paste at: https://github.com/openclaw/openclaw/issues/new

Title

chat.send (WebChat/Control UI/TUI) does not deliver to linked channel even when delivery is enabled; request channel-agnostic “deliver to last/explicit target” support

Body

Summary

When sending messages via Control UI chat or TUI, the message runs internally via chat.send and appears in the gateway transcript (Control UI + TUI), but does not deliver outbound to the linked chat surface (Telegram/WhatsApp/Discord/Slack/etc.).

This makes “operator console” usage confusing because inbound messages from a channel show up everywhere, but replies typed in Control UI/TUI don’t go back out.

#

Version / env

  • OpenClaw: 2026.2.12 (f9e444d)
  • OS: Linux
  • Channel used for repro: Telegram (but request is channel-agnostic)

Repro steps (Telegram example, but applies to any channel)

  1. Ensure a channel is configured and working (Telegram/WhatsApp/Discord/Slack/etc).
  2. In Telegram DM, send a message to the bot.
    • Message shows up in Telegram, Control UI, and TUI (expected).
  3. In Control UI chat input, send a message.
    • Message appears in Control UI + TUI transcript, but nothing is delivered to Telegram.
  4. In TUI, run /deliver on and send a message.
    • Message appears in TUI + Control UI transcript, but nothing is delivered to Telegram.

Expected

#

One of the following (any would solve it), preferably implemented in a channel-agnostic way:

A) chat.send honors a deliver: true flag (like TUI implies) and delivers to:

  • the session’s deliveryContext / last inbound channel+target, OR
  • an explicit target set on the session, OR
  • explicit per-call params (e.g. replyChannel, replyTo, replyAccountId), similar to openclaw agent --deliver.

B) UI/TUI provide a clear setting to set a “delivery target” for the session, and chat.send can deliver there.

Actual

  • Control UI chat does not deliver outbound.
  • TUI /deliver on does not deliver outbound.
  • Only messages originating from the external channel itself (Telegram/etc.) get replies delivered back to that channel.

Workarounds

#
  • Proactive send works (but doesn’t reliably show in UI transcript):
    openclaw message send --channel telegram --target <chatId> --message "..."
  • Agent run + deliver works (and shows in UI transcript):
    openclaw agent --agent main --message "..." --deliver --reply-channel telegram --reply-to <chatId>

Notes / security

If auto-delivery is enabled for chat.send, it should be gated to avoid accidental cross-chat leakage (e.g. require explicit per-session opt-in, respect session.sendPolicy, and/or require explicit target rather than guessing).

Diagnostics attached

  • openclaw sessions --json output (shows only agent:main:main in my case)
  • TUI /status output shows Link channel: unknown even though Telegram is configured/working