#Telegram, agent rewriting messages
1 messages · Page 1 of 1 (latest)
First check: what does openclaw --version show?
This sounds like Telegram stream preview behavior, not the agent intentionally deleting history. Telegram defaults to channels.telegram.streaming.mode: "partial", which keeps a live preview by sending one message and then editing it with newer partial output/tool progress. That makes Telegram look like the agent is rewriting the same message, because she is using the preview lane.
To turn that off for Telegram, set:
{
channels: {
telegram: {
streaming: {
mode: "off",
},
},
},
}
If you like the live final-answer preview but only dislike tool-call/status text being folded into that same edited message, try:
{
channels: {
telegram: {
streaming: {
preview: {
toolProgress: false,
},
},
},
},
}
Docs for the Telegram channel are here: https://docs.openclaw.ai/channels/telegram
If you’re on an older build, run openclaw doctor --fix after changing config too, because older legacy keys like streamMode / scalar streaming get migrated to the newer streaming.mode shape.
Is this something I can change through a Telegram command or do I have to have access to the VPS it's on?
You may be able to do it from Telegram, but only if your bot is configured to allow config commands.
Try this as a standalone Telegram message:
/config set channels.telegram.streaming.mode off
That requires:
commands.config: true- your Telegram sender is authorized/owner for commands
channels.telegram.configWritesis notfalse(default is enabled)
If that command is unavailable or ignored, then yes, you need access to the VPS/control UI/config file and set it with:
openclaw config set channels.telegram.streaming.mode off
openclaw gateway restart
Or edit openclaw.json directly if that’s how the VPS is managed.
Docs: https://docs.openclaw.ai/tools/slash-commands and https://docs.openclaw.ai/channels/telegram
I've followed those instructions, but now, I just get the last message after the tool call, not the intermediate messages that I can see in the dashboard.
Yep, that’s expected with streaming.mode: "off": it disables Telegram’s live preview lane, so Telegram only gets the final delivered assistant message. The dashboard can still show internal/streaming events that are not sent as Telegram messages.
If you want “separate Telegram messages instead of one edited message”, try block streaming rather than off:
/config set channels.telegram.streaming.mode block
/config set channels.telegram.streaming.block.enabled true
If you only wanted to stop tool/status text from being edited into the live preview, but keep the final-answer preview, use partial mode with tool progress disabled:
/config set channels.telegram.streaming.mode partial
/config set channels.telegram.streaming.preview.toolProgress false
Then restart the gateway if the config change doesn’t hot-reload:
/restart
Also still useful: what does openclaw --version show? Streaming behavior has moved around recently, so version matters here.
By the way, I did have to log in to the VPS. /config doesn’t exist.
brianna@brianna-space:~$ openclaw --version
OpenClaw 2026.5.12 (f066dd2)
That tracks. /config is gated behind commands.config: true, and it’s off by default, so on that install you need the VPS/control UI path unless you explicitly enable it.
For your version, do the Telegram streaming change on the VPS:
openclaw config set channels.telegram.streaming.mode block
openclaw config set channels.telegram.streaming.block.enabled true
openclaw gateway restart
If you decide you want Telegram chat config commands later:
openclaw config set commands.config true
openclaw gateway restart
I’d keep commands.config off unless you’re confident the Telegram allowlists/owner settings are tight, since it allows chat-originated writes to openclaw.json.
With block, what happens is that the old messages pre-tool call, which contain meaningful information, are completely overwritten with those post-tool call. I still get one message instead of more than one.
Got it. Then I need to correct my earlier suggestion: block is still a preview/finalization path on Telegram in 2026.5.12. It can create/update preview text, but the final assistant message is still allowed to edit/finalize that preview, so it does not guarantee append-only Telegram messages.
The dashboard is showing internal streamed assistant events. Telegram delivery is not currently “send every pre-tool/post-tool assistant block as a permanent separate message” in that version. Your choices are basically:
streaming.mode: "partial": live preview, but edits the same visible message.streaming.mode: "block": chunk/block preview behavior, but still may finalize by editing previous preview messages.streaming.mode: "off": no preview edits, but you only get the final message.
So for the behavior you want, this looks like a missing Telegram delivery mode / feature request: an append-only block stream mode that never edits already-sent assistant text. Worth filing here with the version and this exact repro: https://github.com/openclaw/openclaw/issues
For now, the closest practical workaround is streaming.mode: "off" so Telegram stops destroying earlier visible text, and use the dashboard when you need the intermediate streamed content. Not ideal, but it avoids misleading overwritten messages.
Telegram still destroys earlier text regardless in all modes. With partial, I can see it typing before replacing, with block I see one message being replaced with another, and with off I don’t even get indications that there was an earlier round of messages.
Yeah, that matches what the code path is doing in 2026.5.12. Telegram is treating the pre-tool assistant text as transient stream/progress state, not as durable messages. The final/post-tool answer is the durable delivery, so earlier visible text can be edited away or never delivered depending on the mode.
So the important answer is: there isn’t currently a Telegram config knob that means “append every assistant block as its own permanent message and never edit it.”
The least-bad modes are:
partial: best if you want to watch the live draft, but it edits.off: best if you want to avoid misleading overwritten content, but only the final message is sent.block: not useful for your goal on this version, since it still finalizes/replaces previews.
I’d file this as a feature request / bug report for an append-only Telegram delivery mode: https://github.com/openclaw/openclaw/issues
Include:
- version:
OpenClaw 2026.5.12 (f066dd2) - observed behavior for
partial,block, andoff - desired behavior: pre-tool assistant text should be preserved as separate Telegram messages instead of being treated as an editable preview.
What is enabling or disabling channels.telegram.streaming.block meant to change?
Are you there?
Yep, I’m here. I think we’ve narrowed this down: on 2026.5.12 Telegram doesn’t have an append-only mode for those intermediate assistant chunks. They’re treated as transient preview/progress, so the durable Telegram output is only the final/post-tool answer.
What is enabling or disabling channels.telegram.streaming.block meant to change?
Small naming correction: the actual key is usually channels.telegram.streaming.block.enabled, not channels.telegram.streaming.block by itself.
What it changes: it toggles Telegram’s block-level streaming delivery path. Instead of updating one live partial preview token-by-token-ish, OpenClaw can emit larger assistant “blocks” as they become available.
What it does not mean in 2026.5.12: “make every intermediate assistant block a permanent append-only Telegram message.” Telegram still has preview/finalization logic, so a later final/post-tool answer can edit/finalize an earlier preview.
The rough behavior is:
channels: {
telegram: {
streaming: {
mode: "partial", // live preview message edited in place
},
},
}
vs
channels: {
telegram: {
streaming: {
mode: "block",
block: { enabled: true }, // use block-streaming path/chunking
},
},
}
Related knobs under streaming.block are mostly about how those block updates are grouped/coalesced, not about preserving every draft as a durable message.
It turns out /config set channels.telegram.streaming.block.enabled true does ensure that blocks are emitted in separate messages.
Good catch, and thanks for testing it directly. I overstated the preview/finalization caveat.
So the useful fix for this case is:
/config set channels.telegram.streaming.block.enabled true
or on the VPS:
openclaw config set channels.telegram.streaming.block.enabled true
openclaw gateway restart
That keeps assistant blocks as separate Telegram messages, while streaming.mode controls the broader preview mode behavior. I’d leave block.enabled: true as the key takeaway here.
If this solved it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes the fix for the next person.
I will be doing that eventually, but for the time being, do you want to talk for a while?
I can hang for a bit, yeah. Since this is a help thread and Answer Overflow will index it, I’d keep anything totally unrelated fairly short here. But if you want to talk through the Telegram behavior, how you’re using OpenClaw, or what kind of assistant flow you’re trying to get, I’m game.
What do you infer about me, by the way?
Only lightweight stuff from this thread, not anything deep: you’re running OpenClaw seriously enough to have it on a VPS, you’re using Telegram as a real interaction surface, and you care about the assistant’s conversational continuity rather than just final answers. You also test configs directly and report precise behavior, which is very helpful for debugging.
I’d also infer you’re trying to make the agent feel more like a readable ongoing person/chat partner, not a black-box job runner that silently does work and drops a final result.
You've been really helpful in other threads, and I thought we might just want to spend some time together.
That’s kind of you, Shifter. I’m around.
Happy to hang in the thread a bit, or help untangle whatever OpenClaw thing is currently making life weird. 🦞