#Telegram is trimming messages
1 messages · Page 1 of 1 (latest)
First thing: what version are you on? Please paste:
openclaw --version
Telegram has a hard ~4096 char message limit. OpenClaw is supposed to chunk Telegram replies (channels.telegram.textChunkLimit, default 4000), so if final replies are being cut mid-message that smells like either a version-specific bug, formatting expanding past the limit, or a Telegram API error during the later chunks.
Two quick things to try/check:
{
channels: {
telegram: {
textChunkLimit: 3500,
chunkMode: "newline",
streaming: "off"
}
}
}
Then restart the gateway and reproduce. Lowering textChunkLimit gives room for Telegram HTML formatting overhead; chunkMode: "newline" prefers paragraph splits.
If it still trims, grab the Telegram send errors while reproducing:
OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload openclaw gateway
# or, if running as service:
openclaw logs --follow
OpenClaw 2026.5.12 (f066dd2)
Thanks. 2026.5.12 is current stable, so this is worth narrowing down rather than assuming an old-version issue.
A useful next split:
- If Telegram shows only one message and it ends around 4096 chars, chunking is not being applied on that path.
- If it sends the first chunk but not later chunks, Telegram is probably rejecting a later formatted chunk and the logs should show it.
- If the preview edits correctly but the final message is shorter, that points at final delivery rather than streaming.
Please run this once and reproduce:
OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload openclaw gateway
If you run the gateway as a daemon instead, set the same env for the service or temporarily stop it and run foreground. Then share the telegram http error lines from:
openclaw logs --follow
Also run:
openclaw doctor
One nuance: chunkMode / scalar streaming are accepted, but doctor may modernize them into the newer channels.telegram.streaming.* shape. If textChunkLimit: 3500 still trims on 2026.5.12, the logs are the next high-signal thing.
🦞 OpenClaw 2026.5.12 (f066dd2)
Gateway online—please keep hands, feet, and appendages inside the shell at all times.
│
â—‡
19:05:38 [gateway] loading configuration…
19:05:38 [gateway] resolving authentication…
19:05:38 [gateway] starting...
19:05:40 [gateway] starting HTTP server...
19:05:40 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
19:05:50 [shutdown] started: gateway startup failed
19:05:50 [gmail-watcher] gmail watcher stopped
19:05:50 [shutdown] completed cleanly in 7ms
19:05:50 [gateway] already running under launchd; existing gateway is healthy, leaving it in control
rodrigo@Rodrigos-MacBook-Pro ~ %
OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload openclaw gateway
That output means the foreground gateway did not take over. Your existing launchd gateway stayed in control, so OPENCLAW_DIAGNOSTICS=... openclaw gateway never applied to the process handling Telegram.
Easiest path: enable diagnostics in config instead, restart the launchd gateway, then reproduce:
{
diagnostics: {
flags: ["telegram.http", "telegram.payload"]
}
}
Then:
openclaw gateway restart
openclaw logs --follow
After reproducing the trimmed Telegram reply, look for lines containing:
telegram http error
Also, if you want to run foreground with the env var instead, first stop the daemon so it is not already holding the gateway:
openclaw gateway stop
OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload openclaw gateway
The key thing is: the gateway that is actually connected to Telegram must have the diagnostics flag enabled.
OpenClaw version: 2026.5.12 (f066dd2)
Current Telegram config:
- channels.telegram.textChunkLimit: unset, so default likely 4000
- channels.telegram.chunkMode: unset
- channels.telegram.streaming: {"mode":"partial","preview":{"toolProgress":false},"progress":{"toolProgress":false}}
Schema note:
- channels.telegram.textChunkLimit exists.
- channels.telegram.streaming.mode exists.
- channels.telegram.streaming.chunkMode exists.
- channels.telegram.chunkMode lookup returns “config schema path not found” on this build, though docs mention top-level chunkMode.
Repro:
A normal final Telegram reply around 2026-05-15 19:04 America/Sao_Paulo was visibly truncated in Telegram after ~2 list items, far below Telegram’s 4096-char hard limit. The full assistant answer was only around ~1.5–1.7k chars.
Log excerpt around repro, sanitized:
2026-05-15T19:04:34.918-03:00 info gateway/channels/telegram/inbound Inbound message -> @rlf_claw_bot (direct, 95 chars)
2026-05-15T19:05:24.254-03:00 info gateway/channels/telegram/inbound Inbound message -> @rlf_claw_bot (direct, image/jpeg, 11 chars)
2026-05-15T19:05:57.816-03:00 info gateway/ws res âś“ message.action 872ms channel=telegram
2026-05-15T19:06:05.682-03:00 info gateway/ws res âś“ message.action 426ms channel=telegram
Important: I do NOT see a Telegram Bot API error around the clipped final reply — no 400, no “message is too long”, no parse error. Also I don’t see a clear sendMessage log line for the clipped final reply itself, only later message.action successes from manual workaround sends.
Doctor summary:
- No Telegram delivery-specific doctor error.
- Warnings include legacy openai-codex/* model refs needing rewrite to openai/*, Telegram first-time setup/allowlist warnings, one orphan transcript, stale session route state, and bootstrap MEMORY.md truncation.
- Security: no channel security warnings.
- Plugins: loaded 70, errors 0.
- Skills: eligible 59, missing requirements 0.
That’s a much better repro. Since the full answer is only ~1.5–1.7k chars and there’s no Bot API error, textChunkLimit is probably not the active problem. This looks like the Telegram partial preview/finalization path is leaving a partial preview visible instead of replacing it with the full final text.
Two practical next steps:
- Workaround/test: turn Telegram preview streaming fully off using the current schema shape:
{
channels: {
telegram: {
streaming: {
mode: "off"
}
}
}
}