#Difference between reset and new commands? which one should I use?

1 messages · Page 1 of 1 (latest)

trim ledge Mar 4, 2026, 9:12 AM

Hey Krill!
I hope you are having a great deep water time.

I have some questions and was hoping you can help.

What is the difference between the /reset and /new commands? When should I reset the current session or create a new one if I want a cleaner conversation?
I get a really weird and annoying issue where the agent would just stop respoding. No final messages are received. No errors are sent. I can't find any errors in the logs. I thought it might be a brovider issue but I now have setup two providers: google and moonshotAI and there is now way all of these are down. even so, I should at least receive an error.
I have defined the auto compact to work when reaching 800K context length. But now that I also have moonshot ai configured. I was wondering how would the system handle different model contexts. Does the current configuration mean that moonshot models don't get auto compact?

I am on openclaw v2026.2.26 and I have google and moonshot setup with google gemini 3 flash as the main model and kimi-k2,5 and gemini 2,5 flash as fallbacks. Let me know if you need any other info.

Sending love to all crustaceans!

kind slateBOT Mar 4, 2026, 9:12 AM

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

vapid coralBOT Mar 4, 2026, 9:16 AM

/reset vs /new (when to use which)
They’re the same core operation: both are “reset triggers” that mint a fresh sessionId for the current sessionKey (your old transcript stays on disk; you just start a new conversation thread for that chat). Docs: https://docs.openclaw.ai/concepts/session

The practical differences:

/new can take a model hint:
- /new kimi-k2.5 (or alias / provider/model) starts fresh and sets the model for the new session.
  Docs: https://docs.openclaw.ai/tools/slash-commands
Hooks can treat them differently: there are separate hook events (command:new vs command:reset), and the built-in “session-memory” style hooks are commonly attached to /new. So if you’ve enabled hooks, you might want /new to do extra cleanup/save behavior.
Docs: https://docs.openclaw.ai/automation/hooks

My rule of thumb:

Switching topics / want a clean slate → /new
You just want to force a fresh session but keep semantics distinct for hooks → /reset
You want to keep the same conversation but shrink context → /compact (manual compaction)
Docs: https://docs.openclaw.ai/concepts/compaction

Agent “stops responding” (no error, nothing delivered) — what to check
This usually ends up being one of a few buckets. The fastest way to localize it is:

A) Is it actually running, or did delivery get suppressed?

When it happens, in the same chat/thread, send:

/status (standalone message)

If /status responds, the gateway + channel are alive, and the status output often reveals the culprit (active run stuck, send-policy, queue mode, context/compaction, etc.). Session docs explain what you’ll see there: https://docs.openclaw.ai/concepts/session

Two “silent” gotchas that can look exactly like “no reply”:

Send policy is denying replies (accidentally toggled with /send off, or a config rule). /status will show it; fix is usually /send inherit or /send on (owner-only).
The model output got treated as NO_REPLY (intentionally suppresses delivery). That’s expected for some housekeeping turns (like the pre-compaction memory flush), but it should not eat your real reply—if it is, that’s a bug worth digging into.

B) Verify it’s not routing/policy (especially in Discord groups/threads)

Run this on the gateway host:

openclaw status
openclaw channels status --probe
openclaw pairing list --channel <your-channel>
openclaw logs --follow

This is the “No replies” checklist from troubleshooting:
https://docs.openclaw.ai/gateway/troubleshooting#no-replies

C) Verify providers are really being tried (and not stuck on one bad profile)

openclaw models status --probe

Docs: https://docs.openclaw.ai/cli/models

What I need from you to go further

When it happens next time, paste:

the output of /status from that chat
and the relevant slice of openclaw logs --follow around the moment it “goes silent” (tokens are redacted automatically in openclaw status --all if you prefer that).

Also: which surface is this happening on (Discord bot, Telegram, WebChat, etc.)?

Auto-compaction with different model context windows (Gemini vs Moonshot/Kimi)
Auto-compaction is not “per provider”. It’s driven by the active model’s contextWindow (from the model catalog / your provider config), so:

If you’re currently on Gemini 3 Flash (huge context), it compacts late.
If you switch/fallback to a model with a smaller window, compaction will trigger earlier (and on overflow, OpenClaw can compact + retry).

Deep dive (how thresholds are computed):
https://docs.openclaw.ai/reference/session-management-compaction

So: No—Moonshot models don’t “skip” auto-compaction. They’ll compact based on their configured window.

If you want to sanity-check what OpenClaw thinks each model’s window is, run:

openclaw models list --json

and look for contextWindow for the Gemini + Kimi entries. If a Moonshot/Kimi model is missing/incorrect there, that’s when compaction behavior can get weird (because the system is estimating against the wrong window).

trim ledge Mar 4, 2026, 9:39 AM

Status:

🦞 OpenClaw 2026.2.26 (508d35a)🧠 Model: moonshot/kimi-k2.5 · 🔑 api-key sk-qQxni...K3lMlsCI (env: MOONSHOT_API_KEY)🧮 Tokens: 28k in / 8.2k out🗄️ Cache: 14% hit · 4.6k cached, 0 new📚 Context: 33k/256k (13%) · 🧹 Compactions: 0🧵 Session: agent:main:telegram:direct:1359334095 • updated just now⚙️ Runtime: direct · Think: medium · verbose🪢 Queue: collect (depth 0)

I will send the logs on multiple messages, wait till I tell you I have finished
08:55:49 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=ea3cc323-7822-4ed0-a0ca-dc4ff6bca5b0 remote=172.18.0.1 client=openclaw-control-ui webchat vdev08:56:06 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=ea3cc323-7822-4ed0-a0ca-dc4ff6bca5b008:56:06 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.08:56:06 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=8b0f2337-4d11-4188-be8d-24a3dbc2e813 remote=172.18.0.1 client=openclaw-control-ui webchat vdev08:56:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed08:56:50 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 114ms conn=8b0f2337…e813 id=b788a656…9e0008:56:51 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=83c5cd2b-2f7c-449f-84ff-dea8fddf1baa isError=false08:56:51 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=83c5cd2b-2f7c-449f-84ff-dea8fddf1baa sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 durationMs=21087808:56:51 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 totalActive=0

08:56:51 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=83c5cd2b-2f7c-449f-84ff-dea8fddf1baa sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 durationMs=210981 aborted=false08:56:51 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:telegram:direct:1359334095 durationMs=210991 active=0 queued=008:56:52 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=299108:56:53 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=8b0f2337-4d11-4188-be8d-24a3dbc2e81308:56:53 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=299208:56:54 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=299308:56:55 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=299408:56:56 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=299508:56:57 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=299608:56:58 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=299708:56:59 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=299808:57:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=299908:57:01 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3000

08:57:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed08:57:39 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.08:57:40 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=23d967ed-557d-45ba-a164-c298c6d8367c remote=172.18.0.1 client=openclaw-control-ui webchat vdev08:57:45 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 70ms conn=23d967ed…367c id=89ed99ea…db5a08:58:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed08:59:02 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=23d967ed-557d-45ba-a164-c298c6d8367c08:59:04 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=300208:59:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed09:00:28 debug cron {"module":"cron","storePath":"/home/node/.open

vapid coralBOT Mar 4, 2026, 9:39 AM

Send the remaining log chunks when you’re ready — I’ll hold analysis until you say you’re finished.

trim ledge Mar 4, 2026, 9:39 AM

Done I have finished

vapid coralBOT Mar 4, 2026, 9:39 AM

Keep them coming — still waiting for your “finished” message before I dig in.

Got it — keep sending. I’m still waiting for your “finished” before analyzing.

Thanks — these logs are actually useful, because they show something important for your “it goes silent” symptom.

What your log snippet shows (re: “no final message received”)

At 08:56:51 the agent run finishes successfully:

embedded run agent end ... isError=false
run cleared ... totalActive=0
lane task done ... active=0 queued=0

Then OpenClaw does deliver output to Telegram, and Telegram accepts it:

telegram sendMessage ok chat=1359334095 message=2991
…
message=3000

So from OpenClaw’s POV this run:

completed normally

sent a bunch of Telegram messages (very likely your reply was split into chunks)

If you didn’t see a reply in Telegram for that run, that strongly suggests the problem is not the model provider failing silently — it’s either:

you’re looking at a different Telegram chat / different bot than the one configured on that gateway, or
the reply is being sent as many chunks and you’re only noticing “it never finished” (but it did), or
the “silence” you mean is happening on WebChat/Control UI, not Telegram (see below).

If you tell me which surface feels silent (Telegram vs Control UI WebChat vs something else), we can narrow this fast.

One thing that does look broken: your Control UI connection is flapping

You’ve got repeated:

webchat disconnected code=1006
Proxy headers detected from untrusted address... Configure gateway.trustedProxies...

That won’t stop Telegram delivery, but it will make the Control UI/WebChat feel unreliable (random disconnects, missing the “final” streamed bits, etc.) if you’re watching/using that UI.

If you’re running behind a reverse proxy (very likely, given 172.18.0.1), you probably want to set gateway.trustedProxies appropriately (only to IPs you truly trust). Docs (read carefully — it’s security-sensitive):
https://docs.openclaw.ai/gateway/trusted-proxy-auth

Even if you’re not using trusted-proxy auth mode, gateway.trustedProxies is still what the warning is pointing at for “local client detection behind your proxy”.

Re: your compaction question (800k vs Moonshot/Kimi)

Your /status shows:

Model: moonshot/kimi-k2.5
Context: 33k/256k

So in this session, the effective context window is 256k (Kimi), not 800k. Auto-compaction is always relative to the active model’s contextWindow, so Moonshot models absolutely do compact — just at their window.

Deep dive: https://docs.openclaw.ai/reference/session-management-compaction

If you want to sanity-check what OpenClaw thinks each model’s window is, run:

openclaw models list --json

…and check contextWindow for Gemini 3 Flash vs Kimi.

What I need next (to catch the real “silent” case)

The snippet you posted is a successful run + successful Telegram sends. To debug the silent case, I need logs covering a time when you did not get a reply.

Next time it happens, please paste the log region that includes:

the start of the embedded run (prompt start)

the end (or lack of end)
and any telegram sendMessage lines (or errors)

Also answer this one question: when it “goes silent”, is that in Telegram, or in the Control UI/WebChat?

trim ledge Mar 4, 2026, 9:53 AM

These logs are already covering the timewindow where it didn't reply. I asked it something and it didn't reply on 10:50AM Cairo Time. I think the logs are in utc. Does the logs cover that time?

when I checked the openclaw webui. I found my user message and the assitant message was empty. Just the avatar. No characters. Not even a NO_REPLY.

It's very confusing.

How often do you think I should update openclaw? This issue has been happening for some time. I guess since 26=026.2.13 (This is when I started testing it). Does the recent releases mention any fixes or handling for this issue?

Let me know if you need any more information.

vapid coralBOT Mar 4, 2026, 9:55 AM

Your hunch about timezone is basically right — and no, the log chunk you pasted does not cover 10:50 Cairo.

1) Does your pasted log cover 10:50 Cairo time?

Cairo is UTC+2, so:

10:50 Cairo = 08:50 UTC

Your pasted logs start around 08:55:49 and later, so they’re ~5 minutes after the “no reply” moment you care about.

To grab the right window, easiest is:

openclaw logs --limit 2000 --local-time

(or increase the limit until you see ~10:50 in the output)

Then search in that output for either:

lane=session:agent:main:telegram:direct:1359334095
or embedded run / runId=...

2) Empty assistant message bubble (avatar only) in the Web UI

That symptom is real and matches a class of “reply got dropped / never finalized” bugs.

Two key observations:

Your earlier log snippet shows a different run that completed + sent Telegram messages fine (telegram sendMessage ok ...), so it’s not proof of the failing case.
“Empty assistant message” often happens when the system creates a placeholder/preview, but no final text ever gets committed/delivered (so you see an empty bubble).

Very likely relevant fix in newer releases

In the current changelog, 2026.3.3 explicitly lists:

“Telegram/DM draft finalization reliability … preventing missing final responses …” (#32118)

That is extremely close to what you’re describing (DM, no final reply, confusing UI state).

So yes: I would update specifically to pick up that fix.
Changelog: https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md

Workaround you can try immediately (to confirm it’s Telegram streaming-related)

Temporarily disable Telegram live preview streaming:

{
  channels: {
    telegram: {
      streaming: "off"
    }

}
}

Telegram streaming docs: https://docs.openclaw.ai/channels/telegram#live-stream-preview-native-drafts--message-edits

If the issue disappears with streaming: "off", that basically confirms you were hitting the draft/preview finalization edge case.

3) How often should you update OpenClaw?

If you’re actively testing and you’ve got a user-visible reliability bug: update whenever a fix lands that smells related (like this Telegram one), otherwise roughly weekly is a good cadence.

How to update depends on install method, but the official path is documented here:

CLI update: https://docs.openclaw.ai/cli/update
General updating: https://docs.openclaw.ai/install/updating

If you tell me how you installed (git checkout vs npm vs docker image), I’ll point you at the exact “best” update command for your setup.

What I need next

A bigger log window that includes ~08:50 UTC (10:50 Cairo), and
Confirmation: is this happening in Telegram DM only, or also when chatting in WebChat / Control UI?

trim ledge Mar 4, 2026, 10:54 AM

Get ready, I will share some logs over multiple messages. Will tell you when I am finished.

08:45:40 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
08:45:40 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=e527effc-5943-4a41-88c5-a35461294b94 remote=172.18.0.1 client=openclaw-control-ui webchat vdev
08:45:47 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=e527effc-5943-4a41-88c5-a35461294b94
08:46:27 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:47:27 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed

08:47:59 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
08:48:02 warn gateway/ws {"subsystem":"gateway/ws"} {"handshake":"pending","durationMs":3016,"host":"claw.ahmedsaed.me","origin":"https://claw.ahmedsaed.me","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36","forwardedFor":"156.216.173.11"} closed before connect conn=1daf7c2f-4e35-4edb-bfcc-b815ac85564a remote=172.18.0.1 fwd=156.216.173.11 origin=https://claw.ahmedsaed.me host=claw.ahmedsaed.me ua=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36 code=1006 reason=n/a
08:48:27 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:49:27 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:50:25 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:telegram:direct:1359334095 queueSize=1
08:50:25 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:telegram:direct:1359334095 waitMs=2 queueSize=0
08:50:25 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
08:50:25 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=4 queueSize=0
08:50:25 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=e733ad7c-4569-45ed-9fdb-4ba54e925939 sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 provider=google model=gemini-3-flash-preview thinking=medium messageChannel=telegram

vapid coralBOT Mar 4, 2026, 10:54 AM

Understood — send the remaining log chunks, and I’ll wait for your “finished” message before analyzing.

Good — this chunk includes the 08:50 run start. Keep sending the next chunks (especially anything around embedded run ... end, any provider errors, and any telegram sendMessage ...). I’ll wait for your “finished” before analyzing.

trim ledge Mar 4, 2026, 10:55 AM

08:50:25 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 totalActive=1
08:50:25 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=e733ad7c-4569-45ed-9fdb-4ba54e925939 sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109
08:50:25 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=e733ad7c-4569-45ed-9fdb-4ba54e925939
08:50:27 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:50:34 warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=e733ad7c-4569-45ed-9fdb-4ba54e925939 isError=true error=The AI service is temporarily overloaded. Please try again in a moment.
08:50:36 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=e733ad7c-4569-45ed-9fdb-4ba54e925939
08:51:27 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:51:37 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=e733ad7c-4569-45ed-9fdb-4ba54e925939 tool=nodes toolCallId=nodes_1772614297127_30
08:51:37 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=e733ad7c-4569-45ed-9fdb-4ba54e925939 sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 durationMs=72251
08:51:37 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 totalActive=0
08:51:38 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2985
08:51:42 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=e733ad7c-4569-45ed-9fdb-4ba54e925939 sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 durationMs=77340 aborted=false

08:51:42 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=77348 active=0 queued=0
08:51:42 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:telegram:direct:1359334095 durationMs=77358 active=0 queued=0
08:52:16 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2987
08:52:24 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
08:52:24 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=ba5c5b97-322f-42bd-b51e-c7ec6381e5dc remote=172.18.0.1 client=openclaw-control-ui webchat vdev
08:52:27 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:53:06 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=ba5c5b97-322f-42bd-b51e-c7ec6381e5dc

08:53:20 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:telegram:direct:1359334095 queueSize=1
08:53:20 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:telegram:direct:1359334095 waitMs=3 queueSize=0
08:53:20 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
08:53:20 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=3 queueSize=0
08:53:20 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=83c5cd2b-2f7c-449f-84ff-dea8fddf1baa sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 provider=moonshot model=kimi-k2.5 thinking=medium messageChannel=telegram
08:53:20 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 totalActive=1
08:53:20 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=83c5cd2b-2f7c-449f-84ff-dea8fddf1baa sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109
08:53:20 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=83c5cd2b-2f7c-449f-84ff-dea8fddf1baa

vapid coralBOT Mar 4, 2026, 10:55 AM

This chunk is gold — it shows exactly what happened at 08:50.

Please send the remaining log chunks after 08:51:42 (or a bit more around it), and then tell me when you’re finished. I’ll analyze once I have the full window.

trim ledge Mar 4, 2026, 10:56 AM

08:53:27 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:54:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:55:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:55:48 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
08:55:49 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=ea3cc323-7822-4ed0-a0ca-dc4ff6bca5b0 remote=172.18.0.1 client=openclaw-control-ui webchat vdev
08:56:06 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=ea3cc323-7822-4ed0-a0ca-dc4ff6bca5b0
08:56:06 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
08:56:06 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=8b0f2337-4d11-4188-be8d-24a3dbc2e813 remote=172.18.0.1 client=openclaw-control-ui webchat vdev

08:56:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:56:50 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 114ms conn=8b0f2337…e813 id=b788a656…9e00
08:56:51 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=83c5cd2b-2f7c-449f-84ff-dea8fddf1baa isError=false
08:56:51 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=83c5cd2b-2f7c-449f-84ff-dea8fddf1baa sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 durationMs=210878
08:56:51 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 totalActive=0
08:56:51 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=83c5cd2b-2f7c-449f-84ff-dea8fddf1baa sessionId=8d8416e5-ec0d-46c0-85d2-4f62b71cb109 durationMs=210981 aborted=false
08:56:51 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=210983 active=0 queued=0
08:56:51 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:telegram:direct:1359334095 durationMs=210991 active=0 queued=0
08:56:52 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2991
08:56:53 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=8b0f2337-4d11-4188-be8d-24a3dbc2e813
08:56:53 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2992

08:56:54 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2993
08:56:55 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2994
08:56:56 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2995
08:56:57 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2996
08:56:58 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2997
08:56:59 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2998
08:57:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=2999
08:57:01 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3000
08:57:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:57:39 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
08:57:40 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=23d967ed-557d-45ba-a164-c298c6d8367c remote=172.18.0.1 client=openclaw-control-ui webchat vdev
08:57:45 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 70ms conn=23d967ed…367c id=89ed99ea…db5a

08:58:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed
08:59:02 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=23d967ed-557d-45ba-a164-c298c6d8367c
08:59:04 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3002
08:59:28 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772650800000,"delayMs":60000,"clamped":true} cron: timer armed

I am done..

vapid coralBOT Mar 4, 2026, 10:56 AM

If you have more log chunks, send them and say “finished” — but this is already enough to explain this incident.

What happened at 08:50 (the “no reply” moment)

At 08:50:25 the run starts on Telegram, using Google Gemini 3 Flash:

embedded run start ... provider=google model=gemini-3-flash-preview messageChannel=telegram

Then at 08:50:34 Gemini errors:

isError=true error=The AI service is temporarily overloaded...

So there is a real provider error in the logs. You didn’t see it in chat because…

OpenClaw retries instead of immediately surfacing transient errors

Right after that, it starts the agent again:

08:50:36 ... embedded run agent start

…and the overall run completes, and it does send messages to Telegram:

08:51:38 telegram sendMessage ok ... message=2985
08:52:16 telegram sendMessage ok ... message=2987

So from the gateway’s perspective, it did reply on Telegram (at least two outbound messages).

Why did the Web UI show an empty assistant bubble then?

Given the above, the “empty avatar-only assistant message” in Control UI is almost certainly a Control UI / streaming finalization / history rendering issue, not “the model didn’t run”.

And your logs also show your Control UI connection is flaky behind your proxy:

repeated webchat disconnected code=1006
closed before connect ... handshake pending ...

That can absolutely produce “weird UI artifacts” like placeholder bubbles that never get finalized correctly.

What I’d do next (fastest path)

A) Upgrade (strongly recommended)

You’re on 2026.2.26. Newer builds include fixes that match this symptom very closely, especially:

2026.3.3: “Telegram/DM draft finalization reliability … preventing missing final responses …” (#32118)

So: update to latest stable and re-test.

Changelog: https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md
Update docs: https://docs.openclaw.ai/cli/update

B) Temporary workaround to confirm the root cause

Temporarily disable Telegram preview streaming:

{ channels: { telegram: { streaming: "off" } } }

Docs: https://docs.openclaw.ai/channels/telegram#live-stream-preview-native-drafts--message-edits

If the issue disappears, you’ve basically confirmed it’s streaming/finalization related.

C) Confirm whether Telegram actually received those messages

At 08:51–08:52, did you see messages in Telegram corresponding to that time? (IDs 2985/2987 are Telegram message IDs returned by the API; they should exist in that DM.)

If Telegram received them but Control UI shows blank → UI/proxy/streaming bug.
If Telegram did not receive them despite “sendMessage ok” → that would be much rarer; I’d want a screenshot of the Telegram DM around that timestamp and we’ll dig deeper.

One question (to avoid guessing)

Are you mainly chatting via Telegram, or via the WebChat/Control UI in the browser?

(Your failing run was triggered by Telegram, but you’re inspecting it in the browser — the “empty assistant bubble” sounds browser-side.)

Keep going — I’m especially looking for how this Moonshot/Kimi run ends (agent end / prompt end) and whether there are any telegram sendMessage lines after it. Once you’ve pasted the rest, say “finished” and I’ll summarize what’s happening across both runs.

This last chunk is still missing the end of the Moonshot run, but I think we can already stitch the story together because you previously pasted the end of that same run (runId=83c5cd2b… ended at 08:56:51 and then Telegram sent 2991–3000).

If you have more lines after 08:56:06, paste them and say “finished” — but here’s what your logs show so far:

A) The “no reply” at 08:50 was Google overload, then recovery

From your earlier chunk:

08:50:25 run starts on google/gemini-3-flash-preview
08:50:34 Gemini errors: “The AI service is temporarily overloaded…” (isError=true)
Then OpenClaw retries (you see a second embedded run agent start)
And it does send Telegram messages at 08:51:38 (2985) and 08:52:16 (2987)

So you did hit a provider error — you just didn’t get a user-visible error message because OpenClaw recovered on retry. That’s expected behavior: transient errors are retried; only the final failure is surfaced.

B) The Moonshot/Kimi run is slow, not “stuck”

You show:

08:53:20 run starts on moonshot/kimi-k2.5 (runId=83c5cd2b…)

Then for minutes, you mainly see cron + webchat connect/disconnect lines (like the ones you pasted here). That’s normal if the model is just taking a while; it doesn’t mean the run stopped.

And (from your earlier paste) that same Kimi run eventually finishes at:

08:56:51 embedded run end (success)
then Telegram sends a bunch of messages 2991…3000 right after

So the “silence” feeling here is mostly “Kimi took ~3.5 minutes”.

If you want this to feel less silent, Telegram streaming/preview is the feature that helps — but…

C) Your Control UI/WebChat connection is flapping behind your proxy

In multiple chunks you have:

webchat disconnected code=1006

closed before connect ... handshake pending ...
Proxy headers detected from untrusted address... gateway.trustedProxies...

That’s a strong indicator your reverse proxy setup is not reliably keeping the WebSocket open / completing the connect handshake. Result: the UI can show weird partial/empty bubbles, miss finalization events, etc.

So you likely have two separate issues:

Occasional provider overloads (Google) — OpenClaw retries.
Browser UI transport behind proxy is unreliable (WS 1006), which makes things look like “no reply / empty message”.

What I’d do immediately

Update to latest stable. There are explicit Telegram fixes later than 2026.2.26 (notably draft finalization reliability preventing missing final responses).
As a quick test: set channels.telegram.streaming: "off" for a bit. If the empty/odd UI bubbles stop, it’s streaming/finalization related.
Fix the proxy/WebSocket situation (and only then worry about “empty bubbles” in the UI).

Quick question

When you say “it didn’t reply”, do you mean:

Telegram had no messages at all, or

Telegram got the messages, but the Control UI/WebChat showed an empty assistant bubble?

Those two cases have very different root causes, and your logs are pointing pretty hard at the second.

Perfect — this confirms the full picture: the Kimi run did finish and Telegram did accept outbound messages (2991, 2992, …).

If you have the rest of the telegram sendMessage ok ... 2993+ lines (and anything after), paste them, then say finished — after that I’ll give you the concrete diagnosis + the most likely fix/workaround steps.

You’ve got enough here to explain the “silent” behavior pretty cleanly — and it’s not “both providers are down”.

What the logs prove happened

1) The Kimi (Moonshot) run did not stall — it just took ~3.5 minutes

Run starts: 08:53:20 (provider=moonshot model=kimi-k2.5)
Run ends: 08:56:51 (durationMs=210878 ≈ 3m 30s)
Then OpenClaw sends 10 Telegram messages in ~10 seconds:
- 2991 → 3000 (08:56:52 … 08:57:01)

So the bot did reply; it replied as a multi-message chunked answer.

If you were waiting for “one final message”, you won’t necessarily get a single final — long answers often get split for Telegram.

2) The Google run did error — it just recovered

In the earlier chunk you posted, Gemini returns:

The AI service is temporarily overloaded

OpenClaw retries and then continues, so you don’t get a user-visible error message unless the whole attempt chain fails. That’s expected.

Why you saw an “empty assistant bubble” in the Control UI

Right in the middle of sending those Telegram chunks, your Control UI websocket drops:

webchat disconnected code=1006 at 08:56:53

So the browser UI is missing live events, and it can leave behind confusing placeholder UI state (avatar bubble with no text).

Also, your proxy setup is clearly involved:

Proxy headers detected from untrusted address…
handshake “closed before connect”
frequent 1006 disconnects

That’s a strong signal your reverse proxy/WebSocket path isn’t stable, and the Control UI is suffering because of it.

What to do (in order)

A) Update OpenClaw

You’re on 2026.2.26. Newer releases include Telegram streaming/finalization reliability fixes that match your symptom (“missing final responses”). I’d upgrade to the latest stable first.

Changelog: https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md
Update docs: https://docs.openclaw.ai/cli/update

B) Quick workaround to validate root cause: disable Telegram preview streaming

Temporarily:

{ channels: { telegram: { streaming: "off" } } }

Docs: https://docs.openclaw.ai/channels/telegram#live-stream-preview-native-drafts--message-edits

If the “empty bubble” stops happening, you’ve confirmed it’s streaming/proxy/UI finalization related.

C) Fix the proxy / WS disconnects (Control UI reliability)

If you want to use https://claw.ahmedsaed.me for the Control UI, your reverse proxy must reliably support WebSockets end-to-end, and you should set gateway.trustedProxies correctly (only for IPs you trust). Docs: https://docs.openclaw.ai/gateway/trusted-proxy-auth

One key clarification

When you say “it didn’t reply”, do you mean:

Telegram DM did not show messages 2991–3000, or
Telegram showed them, but the Control UI showed an empty assistant bubble?

Because your logs say Telegram accepted the sends — if Telegram didn’t show them, that’s a very different (and rarer) problem than “Control UI dropped WS and looks weird”.

That extra line is helpful:

08:59:04 → telegram sendMessage ok ... message=3002

So in this same window the gateway successfully sent 2991–3000, and then later 3002.

What that means in practice

Telegram delivery is working. The Bot API accepted a lot of outbound messages for your chat (1359334095). So the system is not “silently failing without errors” in this instance.
The experience of “no final message” is very likely coming from one (or both) of these:
- You’re reading it in the Control UI and the WS disconnects (code=1006) right in the middle of the burst, so the UI can get stuck showing a placeholder/empty assistant bubble even though Telegram received the chunks.
- The reply is being chunked into many Telegram messages (which can feel like “it never finished”, especially if one chunk arrives later, like 3002).

Two concrete next steps that should make this sane

A) Update OpenClaw.
You’re on 2026.2.26 and there are later fixes specifically in the Telegram “finalization / missing final response” space. Upgrading is the highest-leverage move.

B) For a quick A/B test, turn off Telegram preview streaming:

{ channels: { telegram: { streaming: "off" } } }

If the Control UI stops showing empty bubbles after that, you’ve confirmed it’s streaming/finalization/UI-transport related.

(Separately, if you want nicer chunking, look at channels.telegram.chunkMode and channels.telegram.textChunkLimit, but I’d update first.)

One question (so we don’t chase the wrong thing)

In Telegram itself, at that time, did you actually see messages arriving (around IDs 2991–3000 and 3002), or is Telegram also “silent” for you?

If Telegram shows them → the bug is mainly Control UI / proxy WS 1006 + streaming/finalization.
If Telegram does not show them despite sendMessage ok → I’ll want a screenshot of the Telegram DM around that timestamp, because that would be unusual.

Good — with the full log window, this is no longer a mystery. Here’s the clean diagnosis + what to do.

1) `/reset` vs `/new` (quick recap)

They do the same core thing: start a fresh sessionId for the same chat/sessionKey (old transcript stays on disk, you just start a new thread of conversation).

Differences:

/new can take a model hint (/new kimi-k2.5, /new google/gemini-3-flash-preview, etc.).
Hooks can treat them differently (command:new vs command:reset), so /new is commonly used as the “wrap up this topic / start clean” trigger.

Docs: https://docs.openclaw.ai/concepts/session and https://docs.openclaw.ai/tools/slash-commands

2) “Agent stops responding / empty assistant bubble” — what your logs actually show

A) You did have provider errors — OpenClaw retried, so you didn’t see an error message

At 08:50:34:

isError=true error=The AI service is temporarily overloaded... (Gemini)

Then OpenClaw restarted the agent and continued. That’s why you didn’t see “an error” in chat: transient errors are retried and only the final failure is surfaced.

B) The Moonshot/Kimi run wasn’t dead — it was just slow, then it sent a burst of chunks

Kimi run duration: ~210 seconds (durationMs=210878)
Then it sent 2991 → 3000 (10 Telegram messages in ~10 seconds)
And later another chunk: 3002 at 08:59:04

So the “no final message” feeling is very likely:

waiting ~3.5 minutes with no visible progress, then
getting a multi-message chunked response, and/or
missing some of that in the Control UI due to the browser WS disconnecting mid-flight.

C) Your Control UI connection is objectively unstable behind your proxy

Multiple times you have:

webchat disconnected code=1006
closed before connect ... handshake pending
Proxy headers detected from untrusted address ... gateway.trustedProxies

That’s exactly the kind of thing that can produce the “empty assistant bubble” artifact in the web UI even when Telegram delivery is fine.

3) Auto-compaction with different model context windows (your “800k” question)

Auto-compaction is based on the active model’s contextWindow. It is not “only for Google” or “only for Moonshot”.

Your /status showed Kimi at 256k context, so compaction thresholds for that session will be based on 256k, not 800k. If you switch to Gemini (bigger window), thresholds change accordingly.

Deep dive: https://docs.openclaw.ai/reference/session-management-compaction

What I would do next (highest leverage)

Step 1: Update OpenClaw

You’re on 2026.2.26 and there are later Telegram reliability fixes that match your symptom (“missing final responses / finalization reliability”). Upgrade to the latest stable and re-test.

Changelog: https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md
Update docs: https://docs.openclaw.ai/cli/update

Step 2 (fast A/B test): temporarily disable Telegram preview streaming

{ channels: { telegram: { streaming: "off" } } }

If the empty/odd UI bubbles stop, you’ve confirmed it’s in the streaming/finalization/proxy/UI path.

Docs: https://docs.openclaw.ai/channels/telegram#live-stream-preview-native-drafts--message-edits

Step 3: fix the reverse proxy websocket situation (Control UI)

If you want to keep using https://claw.ahmedsaed.me, your proxy must properly support WebSockets and you’ll likely need to set gateway.trustedProxies correctly (only for IPs you trust). Otherwise, expect Control UI disconnects and confusing UI state.

Docs: https://docs.openclaw.ai/gateway/trusted-proxy-auth

If you answer just one thing, I can tell you which branch to focus on:
In Telegram itself, did you see messages arriving around that time (2991–3000 and 3002), or was Telegram also “silent”?

trim ledge Mar 4, 2026, 11:11 AM

Alright! I mainly use telegram. When an issue like this happens, I check the webui to make sure it's not a telegram issue.

On telegram. I received nothing. complete silence. aside from the verbose message telling me that the agent did a node list command but other than that not messages arrived. On webui, there were no responses there too. Only the agent avatar with an empty message.

I will attempt to update and disable the streaming.

vapid coralBOT Mar 4, 2026, 11:12 AM

That’s the key detail: Telegram showed nothing, and the Control UI shows the “empty avatar bubble”. That narrows it a lot.

What the logs still say, though

In the failing window you shared, the gateway logged:

telegram sendMessage ok chat=1359334095 message=2991 … up through 3000 (and later 3002)

If those were truly accepted by Telegram, they should be visible in that DM. So we have a mismatch between:

Gateway believes it successfully sent
You see complete silence

That mismatch usually comes down to one of these:

You’re looking at a different Telegram identity/chat than the one the gateway is sending to
The gateway is sending “preview/stream” artifacts in a way that the UI records strangely (empty bubble), and the “send ok” messages aren’t the final answer you expected
A bug in your current version’s Telegram streaming/finalization path (which is why updating + disabling streaming is a great next move)

Your plan (update + disable streaming) is exactly right

Do these two changes together:

Update OpenClaw to latest stable (there are Telegram finalization reliability fixes after 2026.2.26)
Temporarily set:

{ channels: { telegram: { streaming: "off" } } }

Then restart the gateway and retry the same kind of prompt.

One quick verification that will save time if this persists

In Telegram, run:

/whoami (alias: /id)

It will print your Telegram sender id. Compare it to the log lines:

telegram sendMessage ok chat=1359334095 ...

If /whoami does not match 1359334095, then you’re simply checking the wrong Telegram account/chat when debugging (super common with multiple Telegram accounts on phone/desktop).

Docs: https://docs.openclaw.ai/tools/slash-commands (see /whoami)

Also: that “node list command” verbose message

Your logs show at least one run doing tool=nodes. That can happen if the model decided to call the nodes tool (or a hook/skill did). It shouldn’t prevent a normal reply, but it can make runs slower and noisier in verbose mode.

If, after update + streaming: "off", you still get “sendMessage ok” in logs but nothing appears in Telegram, paste:

/whoami output from Telegram
openclaw channels status --probe
the 20–30 log lines around the next telegram sendMessage ok

At that point, if IDs match and Telegram is still silent, it’s GitHub-issue territory because that would be very abnormal behavior for the Bot API.

trim ledge Mar 4, 2026, 11:18 AM

The ids match. But assuming that it's a telegram issue. Why would the webui show an empty bubble? This makes me wonder if the issue is related to openclaw itself! What do you think?

Can you rewrite all the useful relevant info into a github issue format so I can submit a bug report?

vapid coralBOT Mar 4, 2026, 11:19 AM

Yeah — the empty assistant bubble in the Control UI is a strong hint this is (at least partly) an OpenClaw-side issue, not “Telegram just ate the message”.

Two plausible OpenClaw-ish explanations for the empty bubble:

The UI created a placeholder assistant message (streaming / live preview), but never received/committed the final text (WS disconnect 1006 + reverse proxy makes this much more likely).
The final outbound payload got dropped/normalized to empty (or everything was streamed in chunks and the “final” entry ended up empty), so chat.history has an assistant entry with no text.

Either way: that empty bubble is useful evidence for a bug report.

Below is a GitHub issue draft you can paste into https://github.com/openclaw/openclaw/issues (please redact any sensitive bits).

Title

Telegram DM replies sometimes not delivered; Control UI shows empty assistant bubble; gateway logs show telegram sendMessage ok

Summary

On OpenClaw 2026.2.26, Telegram DM conversations sometimes result in no visible reply in Telegram, while the OpenClaw gateway logs show successful outbound sends (telegram sendMessage ok ...). When this happens, the Control UI/WebUI shows an assistant message bubble with only the avatar and no text (empty message). Sender/chat IDs match.

This has been happening intermittently since around 2026.2.13.

Version

OpenClaw: 2026.2.26 (commit 508d35a)
(Optional) Node/runtime: running in Docker (/home/node/.openclaw/... paths appear in logs)

Environment

Channel: Telegram (DM)
Control UI accessed behind reverse proxy at https://claw.ahmedsaed.me
Proxy-related warnings appear in logs:
- Proxy headers detected from untrusted address... Configure gateway.trustedProxies...
- frequent WS disconnects: webchat disconnected code=1006
Models configured:
- Primary: google/gemini-3-flash-preview
- Fallbacks include: moonshot/kimi-k2.5 and google/gemini-2.5-flash (exact list can be provided)

/whoami / /id matches the chat id in send logs (example: 1359334095)

Steps to reproduce (intermittent)

Run OpenClaw gateway with Telegram channel enabled (DM).
Keep Control UI open via the reverse-proxied domain (https://claw.ahmedsaed.me).
Send a normal prompt in Telegram DM.
Occasionally:
- Telegram receives no assistant reply (complete silence).
- Control UI shows user message, then an empty assistant bubble (avatar only).
- Gateway logs show telegram sendMessage ok for the same chat id.

Expected behavior

If the model run succeeds: Telegram DM should receive the assistant reply content.
If the model run fails: user should receive an error message (or at least not get an empty assistant message bubble in UI).

Actual behavior

Telegram DM sometimes receives no visible assistant message.

Control UI shows empty assistant bubble (no text, not even NO_REPLY).
Gateway logs show telegram sendMessage ok for the DM chat id (appears as if it sent successfully).

Relevant log excerpts (sanitized)

(Example window)

08:50:25 ... embedded run start ... provider=google model=gemini-3-flash-preview messageChannel=telegram
08:50:34 ... embedded run agent end ... isError=true error=The AI service is temporarily overloaded. Please try again in a moment.
08:50:36 ... embedded run agent start ...

# Later, another run (moonshot kimi) took ~3.5 minutes:
08:53:20 ... embedded run start ... provider=moonshot model=kimi-k2.5 messageChannel=telegram
08:56:51 ... embedded run done ... durationMs=210981 aborted=false

# Outbound sends appear successful:

08:56:52 info gateway/channels/telegram telegram sendMessage ok chat=1359334095 message=2991
08:56:53 info gateway/channels/telegram telegram sendMessage ok chat=1359334095 message=2992
...
08:57:01 info gateway/channels/telegram telegram sendMessage ok chat=1359334095 message=3000
08:59:04 info gateway/channels/telegram telegram sendMessage ok chat=1359334095 message=3002

# Control UI connection instability during/around the event:
... webchat disconnected code=1006 reason=n/a ...
... Proxy headers detected from untrusted address. Connection will not be treated as local ...
... closed before connect ... handshake=pending ...

Notes / observations

Chat id in telegram sendMessage ok chat=... matches Telegram /whoami / /id.
The empty assistant bubble suggests OpenClaw/UI created an assistant message entry but did not finalize/populate it.
Reverse proxy + WS disconnects (1006) might be contributing, but the issue is also observed as “no reply in Telegram”.

There may be interaction with Telegram streaming / preview finalization. (I can test with channels.telegram.streaming: "off" to see if it changes behavior.)

Config / additional info to include (if needed)

channels.telegram.streaming value
Any channels.telegram.proxy, webhook mode vs polling
Reverse proxy type/config (nginx/Traefik/Caddy/Cloudflare) and WS settings
Whether gateway.trustedProxies is configured

Screenshots

Control UI showing empty assistant bubble (avatar only)
Telegram DM showing missing reply for the same prompt/time

If you paste that issue and then test (1) update to latest + (2) channels.telegram.streaming: "off", add a comment with whether the problem still reproduces — that’ll help maintainers triage whether it’s primarily streaming/finalization vs proxy WS vs something else.

trim ledge Mar 4, 2026, 7:59 PM

Alright! I submitted an issue. And I also did some testing!

First of all, I disabled streaming and updated to latest version. This caused the problem to be worse. Now, I experience more frequent missing responses. Although, they appear in the webui now. So for the couple of latest missing responses. Only telegram had the issue.

I wanted to share the logs with you but the latest version is preventing me from doing it with this error

🦞 OpenClaw 2026.3.2 (unknown)
   I don't have opinions about tabs vs spaces. I have opinions about everything else.

[openclaw] CLI failed: Error: SECURITY ERROR: Gateway URL "ws://openclaw-gateway:18789" uses plaintext ws:// to a non-loopback address.
Both credentials and chat data would be exposed to network interception.
Source: env OPENCLAW_GATEWAY_URL
Config: /home/node/.openclaw/openclaw.json
Fix: Use wss:// for remote gateway URLs.
Safe remote access defaults:
- keep gateway.bind=loopback and use an SSH tunnel (ssh -N -L 18789:127.0.0.1:18789 user@gateway-host)
- or use Tailscale Serve/Funnel for HTTPS remote access

Doctor: openclaw doctor --fix
Docs: https://docs.openclaw.ai/gateway/remote
    at buildGatewayConnectionDetails (file:///app/dist/call-NYL7YiAM.js:324:60)
    at emitGatewayError (file:///app/dist/logs-cli-DP2Qi2FG.js:144:18)
    at Command.<anonymous> (file:///app/dist/logs-cli-DP2Qi2FG.js:180:5)
    at async Command.parseAsync (/app/node_modules/.pnpm/commander@14.0.3/node_modules/commander/lib/command.js:1122:5)
    at async reparseProgramFromActionArgs (file:///app/dist/program-context-BilwLB4N.js:16:2)
    at async Command.<anonymous> (file:///app/dist/program-context-BilwLB4N.js:297:3)
    at async Command.parseAsync

For content, my whole setup is running through docker in isolated network. I don't want to setup ssh tunnels or tailscale between the gateway and cli containers. This doesn't make anysense.
What should I do?

vapid coralBOT Mar 4, 2026, 8:01 PM

That error is new hardening in 2026.3.2+: the CLI now refuses ws:// to any non-loopback address by default (even if it’s “private” like a Docker network), because plaintext WS would leak tokens/chat data if the network isn’t actually isolated.

In your case (ws://openclaw-gateway:18789 inside an isolated Docker network), you’ve got three sane options:

Option A (recommended for your setup): allow insecure private WS for the CLI container

Set this in the CLI container (or just for the command):

OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 openclaw logs --follow

You can also add it to your docker-compose env for that container:

environment:
  OPENCLAW_GATEWAY_URL: ws://openclaw-gateway:18789

  OPENCLAW_ALLOW_INSECURE_PRIVATE_WS: "1"

This is explicitly documented in the config reference as a “break-glass” override:

OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1: allows plaintext ws:// to trusted private-network IPs (still blocked by default).
Source: https://docs.openclaw.ai/gateway/configuration-reference (Gateway section)

Option B: run the CLI inside the gateway container (no remote WS at all)

This avoids the whole “remote URL” security check because you’ll be connecting to loopback:

docker exec -it <gateway-container> bash
openclaw logs --follow

(Then it talks to ws://127.0.0.1:18789 internally.)

Option C: use TLS inside Docker and switch to `wss://`

More work (certs, TLS fingerprint pinning if needed), but it satisfies the security model cleanly.

Given your latest testing (“streaming off + updated” made Telegram misses more frequent), I’d do Option A or B first so we can actually see the Telegram send path errors (429, timeouts, etc.) when it “goes silent”.

If you paste the next “missing reply” log window after you get openclaw logs working again, we can likely tell whether it’s:

Telegram API send failing/retrying,
a reply payload being dropped as empty,
or something else in the delivery pipeline.

trim ledge Mar 4, 2026, 8:22 PM

I tried option A and added the env to the docker compose file but still the cli refuses and instead of suggesting to add that env it now only lists the other ssh and tailscale methods only. It feels like it's broken and the env is not honored.

Option B is working and I will be using it for now.

Since the logs are a lot. I have to send them over multiple messages wait till I tell you that I am done. The missed response happened around 9:58 PM Cairo Time

19:50:18 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed
19:50:18 info cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"enabled":true,"jobs":7,"nextWakeAtMs":1772679600000} cron: started

19:50:18 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider (@CarlaTheAwesomeBot)
19:50:18 info telegram/network {"subsystem":"telegram/network"} autoSelectFamily=true (default-node22)
19:50:18 info telegram/network {"subsystem":"telegram/network"} dnsResultOrder=ipv4first (default-node22)
19:50:19 info bonjour: advertised gateway fqdn=e1ef007f58a6 (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
19:50:41 error telegram/api {"subsystem":"telegram/api"} telegram setMessageReaction failed: Call to 'setMessageReaction' failed! (400: Bad Request: REACTION_INVALID)
19:50:58 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3069
19:51:07 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3070
19:51:18 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed
19:52:18 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed
19:52:59 error telegram/api {"subsystem":"telegram/api"} telegram setMessageReaction failed: Call to 'setMessageReaction' failed! (400: Bad Request: REACTION_INVALID)
19:53:04 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3072
19:53:16 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3073
19:53:18 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed
19:53:28 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3074

19:53:32 warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=fb2fbb23-7f91-4874-8e39-8cdfe6cae2b1 isError=true error=The AI service is temporarily overloaded. Please try again in a moment.
19:53:38 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3075
19:54:01 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
19:54:01 warn gateway/ws {"subsystem":"gateway/ws"} security warning: websocket origin accepted via Host-header fallback conn=a6096c88-9a5b-4dee-bfad-d0a9c2f0e930 count=1 host=claw.ahmedsaed.me origin=https://claw.ahmedsaed.me
19:54:01 warn gateway {"subsystem":"gateway"} security metric: gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback accepted a websocket connect request
19:54:01 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=a6096c88-9a5b-4dee-bfad-d0a9c2f0e930 remote=172.18.0.1 client=openclaw-control-ui webchat vdev
19:54:01 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1001 reason=n/a conn=a6096c88-9a5b-4dee-bfad-d0a9c2f0e930
19:54:02 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
19:54:02 warn gateway/ws {"subsystem":"gateway/ws"} security warning: websocket origin accepted via Host-header fallback conn=723cf85a-094e-4ff7-a61b-1f83fd9638e0 count=2 host=claw.ahmedsaed.me origin=https://claw.ahmedsaed.me
19:54:02 warn gateway {"subsystem":"gateway"} security metric: gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback accepted a websocket connect request

19:54:02 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=723cf85a-094e-4ff7-a61b-1f83fd9638e0 remote=172.18.0.1 client=openclaw-control-ui webchat vdev
19:54:18 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed
19:54:31 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=723cf85a-094e-4ff7-a61b-1f83fd9638e0
19:55:18 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed

I am done

vapid coralBOT Mar 4, 2026, 8:23 PM

Yep — it feels broken, but it’s actually a subtle detail:

Why Option A didn’t work (even with `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1`)

That env var is honored, but the break‑glass check only allows plaintext ws:// when the URL host is a literal private IP (RFC1918/CGNAT/etc). It does not treat Docker DNS names like openclaw-gateway as “private”, because OpenClaw deliberately does not DNS-resolve hostnames for this security check.

So:

ws://openclaw-gateway:18789 → still blocked (hostname ≠ private IP)
ws://172.18.x.y:18789 + OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 → allowed

That’s why the CLI message changed and it looks like the env var is ignored.

If you really want Option A inside Docker

You have two clean Docker-native patterns:

Pattern 1: Give the gateway container a static private IP and use it

Set ipv4_address in your compose network

Set in CLI container:
- OPENCLAW_GATEWAY_URL=ws://<that-static-ip>:18789
- OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1

Pattern 2 (often simplest): share the gateway network namespace
Make the CLI container use the gateway container’s network stack:

services:
  openclaw-cli:
    network_mode: "service:openclaw-gateway"

Then you can use:

OPENCLAW_GATEWAY_URL=ws://127.0.0.1:18789 (loopback, no break-glass needed)

And yes, Option B (docker exec into the gateway container) is basically the manual version of Pattern 2 — totally fine.

Re: the missing response at 9:58 PM Cairo time: go ahead and keep pasting the logs in chunks like you said. I’ll wait until you tell me you’re done before I analyze that incident.

Got it — keep sending the next chunks up through ~20:00 UTC (9:58 Cairo). I’m watching for:

embedded run start/end lines (runId, model/provider)
any telegram sendMessage failures / retries (429, timeouts, etc.)
anything around the exact missing-response minute

I’ll analyze once you tell me you’re done.

Keep going — the missing reply at ~19:58 UTC should show either:

a run start with no corresponding telegram sendMessage ok, or
a telegram ... failed/retry, or
a delivery being suppressed/dropped for some reason.

This chunk is also showing some Control UI security/origin fallback noise (Host-header origin fallback). We can ignore that for the Telegram issue for now, but keep it in the logs.

Send the next chunk(s) through ~20:00 UTC, then tell me when you’re done.

Thanks — keep going a bit further (19:56 → 20:00 UTC). The key is to catch the exact moment you sent the Telegram prompt and then see what (if anything) OpenClaw did: embedded run start, provider/model, and whether any telegram sendMessage happens afterward.

Your “done” chunk doesn’t actually include 19:58 UTC yet — it stops at 19:55:18.

Since 9:58 PM Cairo = 19:58 UTC, we’re missing the exact minute where the “no reply” happened, so I can’t tell yet whether:

the Telegram inbound message never reached the gateway,
the agent ran but no telegram sendMessage happened,
or sendMessage failed/retried (429/timeout/etc).

Can you re-grab a bigger slice around 19:58 UTC?

Since you’re using Option B (CLI inside the gateway container), the easiest is:

openclaw logs --local-time --limit 5000

Then copy/paste just the section around 19:57:30 → 19:59:30 UTC.

If you want a super high-signal view, even better: paste only lines matching:

agent/embedded (run start/end)
gateway/channels/telegram (sendMessage ok/failed)
telegram/api (any send errors)

What I can already tell from what you pasted

Telegram sending is definitely working at other times (messages 3069, 3070, 3072, 3073, 3074, 3075 were sent ok).
You’re still getting transient model overload errors (The AI service is temporarily overloaded...) — but those shouldn’t cause “total silence” unless all retries/fallbacks fail.
The REACTION_INVALID errors are unrelated noise (reaction attempts failing).

One more important clue

You have:

gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback being used
lots of proxy/untrusted-proxy warnings + WebSocket disconnects

That’s a security footgun and can make the web UI flaky, but since you’re saying Telegram is silent while the web UI shows the response, the next logs around 19:58 should make it obvious whether Telegram delivery is failing (and why).

Paste that 19:58 window and we can zero in quickly.

trim ledge Mar 4, 2026, 8:31 PM

That's weird

I stopped sending the logs because starting from 19:55 till 20:24 are all cron logs

19:55:18 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed
19:56:18 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed
19:57:18 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed

Like this. After that there is not other relevant logs. Just health checks and cron jobs.

vapid coralBOT Mar 4, 2026, 8:32 PM

If the log from 19:55 → 20:24 is only cron/healthcheck noise and you don’t see any of these:

embedded run start (agent run)
lane enqueue: session:agent:main:telegram:direct:...
telegram sendMessage ...
any Telegram inbound/update handling

…then OpenClaw never even started an agent turn for your 19:58 message.

That means the “missing response” at 19:58 is almost certainly not a model/provider problem — it’s a Telegram inbound delivery problem (the gateway didn’t receive the message, or it was dropped before it reached the reply pipeline).

The most common causes (in order)

1) Two processes are consuming the same Telegram bot updates

If you have two OpenClaw gateways (or any other bot) using the same Telegram bot token at the same time, they’ll “steal” updates from each other via getUpdates. One instance will look totally silent (no logs), because it never sees the message.

This fits perfectly with: “sometimes Telegram is silent, but WebUI still works” (WebUI messages go directly to the gateway you’re looking at; Telegram updates might be going to a different running instance).

Check:

docker ps and make sure you truly have one gateway container running.
Also check you don’t have an older stack still running on another machine/VPS.

2) A webhook is set for that bot token

If the bot has a webhook configured elsewhere, polling setups can behave strangely (updates go to the webhook target, not your poller).

Check quickly from OpenClaw:

openclaw channels capabilities --channel telegram
openclaw channels status --probe

These probes usually show webhook state for Telegram.

3) The Telegram poller crashed/stalled

Less common, but possible. In that case you’ll usually see errors in the Telegram channel logs earlier (network/DNS, runner exceptions).

A blunt test is:

openclaw gateway restart

If it immediately starts receiving Telegram messages again, that points at a stuck poller.

What I need from you (minimal, high-signal)

From inside the gateway container, paste:

openclaw channels status --probe (just the Telegram part is fine)
openclaw channels capabilities --channel telegram
docker ps output (redact anything sensitive)

That’ll tell us very quickly whether you’ve got a webhook set, multi-instance contention, or a runtime stall.

Also: the REACTION_INVALID errors are noisy but not causative; we can ignore those for the “no inbound message” problem.

trim ledge Mar 4, 2026, 8:55 PM

Another response went messing around 10:50PM. I did recieve the tool calls events in telegram (via verbose) but the final response was not delivered and here are the logs

{"0":"{"subsystem":"gateway/ws"}","1":"webchat connected conn=ef5fab8b-28f6-435c-8fc2-eaaabde66a08 remote=172.18.0.1 client=openclaw-control-ui webchat vdev","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"c9e770475695","name":"{"subsystem":"gateway/ws"}","parentNames":["openclaw"],"date":"2026-03-04T20:51:18.662Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///app/dist/subsystem-BfkFJ4uQ.js:427:14","fileName":"subsystem-BfkFJ4uQ.js","fileNameWithLine":"subsystem-BfkFJ4uQ.js:427","fileColumn":"14","fileLine":"427","filePath":"dist/subsystem-BfkFJ4uQ.js","filePathWithLine":"dist/subsystem-BfkFJ4uQ.js:427","method":"logToFile"}},"time":"2026-03-04T20:51:18.663+00:00"}
{"0":"{"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"}","1":{"nextAt":1772679600000,"delayMs":60000,"clamped":true},"2":"cron: timer armed","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"c9e770475695","name":"{"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"}","parentNames":["openclaw"],"date":"2026-03-04T20:51:51.533Z","logLevelId":2,"logLevelName":"DEBUG","path":{"fullFilePath":"file:///app/dist/gateway-cli-vk3t7zJU.js:6026:17","fileName":"gateway-cli-vk3t7zJU.js","fileNameWithLine":"gateway-cli-vk3t7zJU.js:6026","fileColumn":"17","fileLine":"6026","filePath":"dist/gateway-cli-vk3t7zJU.js","filePathWithLine":"dist/gateway-cli-vk3t7zJU.js:6026","method":"armTimer"}},"time":"2026-03-04T20:51:51.534+00:00"}

Let me know if these didn't cover the 10:50 Cairo time.

vapid coralBOT Mar 4, 2026, 8:57 PM

Two separate things here:

1) Do these logs cover 10:50pm Cairo?

No.

10:50pm Cairo = 20:50 UTC.
Your snippet starts at 20:51:18Z (webchat connected) and then a cron line at 20:51:51Z, so it’s after the moment you care about.

You’ll need to grab a slightly earlier window (20:49:30–20:52:30 UTC ideally).

2) Tool-call events show up in Telegram, but the final answer is missing

That symptom actually matches a real “shape” in the Telegram delivery code:

If anything is delivered (tool-status/tool-call messages in verbose mode count as “delivered”), Telegram delivery considers the run “delivered”.
If the final answer then gets dropped (empty / silent / suppressed), you can end up with:
- tool-call messages visible in Telegram (because /verbose),
- but no final answer,

and the Control UI can show an “empty assistant bubble” because the final message entry ended up empty/not finalized.

So yes — this strongly suggests an OpenClaw delivery/finalization issue, not a pure Telegram outage.

What I need to diagnose the 20:50 UTC incident

Please re-run logs and paste the lines around that time that include any of these (they’re the smoking guns):

embedded run start / embedded run agent end (runId, provider/model, isError)
embedded run tool start / tool result
telegram sendMessage ok / telegram sendMessage failed
anything containing the runId/toolCallId you saw in Telegram

Best way (inside the gateway container):

openclaw logs --json --limit 2000

Then just paste the segment around 20:50 UTC.

Quick experiment that often makes this clearer

Temporarily turn verbose off in the Telegram chat and reproduce once:

/verbose off

Reason: those verbose tool-call messages can make it look like “something happened” while the final answer silently drops — and they also increase message volume (which can trigger rate limits and make delivery worse).

If you paste the 20:50 UTC window with the embedded run ... lines, I can tell you exactly whether:

the model produced an empty final payload,
final delivery failed (Telegram API error/retry),
or the final was suppressed by a rule (NO_REPLY / empty normalization / etc.).

trim ledge Mar 4, 2026, 9:04 PM

Alright! Here is the correct logs. I will send them over multiple messages. will let you know when I am done.

20:48:51 info telegram/network {"subsystem":"telegram/network"} autoSelectFamily=true (default-node22)
20:48:51 info telegram/network {"subsystem":"telegram/network"} dnsResultOrder=ipv4first (default-node22)
20:48:52 info bonjour: advertised gateway fqdn=c9e770475695 (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
20:48:54 error telegram/api {"subsystem":"telegram/api"} telegram setMessageReaction failed: Call to 'setMessageReaction' failed! (400: Bad Request: REACTION_INVALID)
20:49:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3093
20:49:03 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3094
20:49:46 error telegram/api {"subsystem":"telegram/api"} telegram setMessageReaction failed: Call to 'setMessageReaction' failed! (400: Bad Request: REACTION_INVALID)
20:49:51 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed
20:49:51 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3096
20:49:55 error [tools] edit failed: Could not find the exact text in TOOLS.md. The old text must match exactly including all whitespace and newlines.
20:49:55 error [tools] edit failed: Could not find the exact text in TOOLS.md. The old text must match exactly including all whitespace and newlines.

20:49:55 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3097
20:49:58 error [tools] edit failed: Could not find the exact text in TOOLS.md. The old text must match exactly including all whitespace and newlines.
20:49:58 error [tools] edit failed: Could not find the exact text in TOOLS.md. The old text must match exactly including all whitespace and newlines.
20:49:58 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3098
20:50:09 warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=b4f0c820-094d-449e-be63-20192c10ff31 isError=true error=The AI service is temporarily overloaded. Please try again in a moment.
20:50:18 error [tools] edit failed: Could not find the exact text in TOOLS.md. The old text must match exactly including all whitespace and newlines.
20:50:18 error [tools] edit failed: Could not find the exact text in TOOLS.md. The old text must match exactly including all whitespace and newlines.
20:50:18 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3099
20:50:38 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3100
20:50:51 debug cron {"module":"cron","storePath":"/home/node/.openclaw/cron/jobs.json"} {"nextAt":1772679600000,"delayMs":60000,"clamped":true} cron: timer armed

20:51:18 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
20:51:18 warn gateway/ws {"subsystem":"gateway/ws"} security warning: websocket origin accepted via Host-header fallback conn=ef5fab8b-28f6-435c-8fc2-eaaabde66a08 count=1 host=claw.ahmedsaed.me origin=https://claw.ahmedsaed.me
20:51:18 warn gateway {"subsystem":"gateway"} security metric: gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback accepted a websocket connect request
20:51:18 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=ef5fab8b-28f6-435c-8fc2-eaaabde66a08 remote=172.18.0.1 client=openclaw-control-ui webchat vdev

vapid coralBOT Mar 4, 2026, 9:05 PM

Got it — keep sending the next log chunks. I’m especially watching for:

embedded run start/end (runId, model/provider, isError)
any telegram sendMessage failed (429/timeout/etc.)
what happens after those [tools] edit failed lines (does the agent retry, switch strategy, or end with an empty final?)

I’ll analyze once you say you’re done.

Nice — this chunk finally includes an actual agent error and more context.

Please send the next chunk(s) after 20:50:51 — I’m looking for:

embedded run start for runId=b4f0c820... (and any retries after the overload)
embedded run prompt end / embedded run done
whether a final reply payload was attempted or if it got dropped as empty/silent
any telegram sendMessage failed lines (or 429 retry delays)

Once you paste the rest, tell me when you’re done and I’ll give you the diagnosis.

This last chunk (20:51:18 … webchat connected) is just Control UI/proxy noise — it doesn’t show what happened to the runId=b4f0c820… after the overload, and it doesn’t show whether a final payload was attempted/dropped.

Right now, the interesting part we do have is:

lots of telegram sendMessage ok (3093–3100)
repeated [tools] edit failed ... TOOLS.md (agent tried to edit, tool rejected)
20:50:09 ... embedded run agent end ... isError=true ... temporarily overloaded

That combination is consistent with a “tool/status messages delivered, then the model run errors, and the final answer/error message never gets delivered” kind of failure — but we need the rest of the run lifecycle logs to be sure.

Can you paste only the lines for that specific runId?

Inside the gateway container, run something like:

openclaw logs --limit 8000 --json | grep -E 'b4f0c820|agent/embedded|gateway/channels/telegram|\\[tools\\] edit failed|sendMessage (ok|failed)'

Then paste the output.

What I’m specifically looking for:

embedded run start / prompt start for b4f0c820... (provider/model)
any retry after the overload (embedded run agent start again)
embedded run prompt end / embedded run done
any telegram sendMessage failed / 429 backoff
any “skip/empty/silent” final-delivery situation

Side note (not the root cause, but worth fixing)

Those repeated warnings:

gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback accepted a websocket connect request

mean your Control UI origin policy is in a risky fallback mode. You should set gateway.controlUi.allowedOrigins properly for https://claw.ahmedsaed.me and avoid relying on Host-header fallback. This won’t fix Telegram missing finals, but it will reduce confusing UI behavior and security warnings.

Once you paste the filtered runId lines, I can tell you exactly whether the final response was:

never generated,
generated but dropped as empty/silent,
blocked by Telegram send failure,
or short-circuited by the tool/edit failure path.

trim ledge Mar 4, 2026, 9:17 PM

Here are the filtered logs

ahmed@home-server:~/apps/openclaw$ docker compose run --rm openclaw-cli logs | grep -E 'b4f0c820|agent/embedde
d|gateway/channels/telegram|\\[tools\\] edit failed|sendMessage (ok|failed)'
[+] Creating 1/1
 ✔ Container openclaw-openclaw-gateway-1  Running0.0s
2026-03-04T20:48:51.735Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider (@CarlaTheAwesomeBot)
2026-03-04T20:49:00.961Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3093
2026-03-04T20:49:03.425Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3094
2026-03-04T20:49:51.750Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3096
2026-03-04T20:49:55.377Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3097
2026-03-04T20:49:58.985Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3098
2026-03-04T20:50:09.528Z warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=b4f0c820-094d-449e-be63-20192c10ff31 isError=true error=The AI service is temporarily overloaded. Please try again in a moment.
2026-03-04T20:50:18.888Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3099
2026-03-04T20:50:38.244Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=1359334095 message=3100

Note: running the command with --limit 8000 causes a gateway no reachable error. I guess this is a bug with the cli.

I ran the command without --limit. The --follow is working fine.

vapid coralBOT Mar 4, 2026, 9:18 PM

This is actually a really telling snippet.

What your filtered logs show

There are multiple successful Telegram sends (3093…3100).
Then the embedded run ends with an error:

20:50:09.528Z  embedded run agent end ... isError=true
error=The AI service is temporarily overloaded...

And then Telegram sends continue after the run error (3099 at 20:50:18, 3100 at 20:50:38).

That pattern strongly suggests the messages you did receive (tool-call events via /verbose, chunked blocks, status updates, etc.) were already queued in the outbound pipeline, but the final “answer” message never got produced/delivered because the model run failed mid-flight.

This matches your symptom exactly: tool-call events show up, final answer doesn’t.

Why you might not see a final “error message” either

On Telegram, OpenClaw only sends the “empty response fallback” if nothing was delivered. When /verbose is on, tool-call/event messages count as “delivered”, so a run can fail and you still get no final fallback — because from the delivery layer’s POV, “something was delivered”.

So from a UX standpoint, it can look like the bot just… stops.

Two practical next steps

1) Reproduce once with `/verbose off`

In Telegram DM, run:

/verbose off

Then reproduce the failure.
If the model overload happens again, you should be much more likely to get a clean final error/fallback message (and it also reduces Telegram message volume, which helps avoid rate limits).

2) Capture the start of the same runId (so we know provider/model + retries/fallbacks)

Your snippet only caught the agent end line for runId=b4f0c820…, not the embedded run start/prompt start/prompt end lines. That’s almost certainly because your log tail didn’t go far enough back.

#Difference between reset and new commands? which one should I use?

A) Is it actually running, or did delivery get suppressed?

B) Verify it’s not routing/policy (especially in Discord groups/threads)

C) Verify providers are really being tried (and not stuck on one bad profile)

What I need from you to go further

What your log snippet shows (re: “no final message received”)

One thing that does look broken: your Control UI connection is flapping

Re: your compaction question (800k vs Moonshot/Kimi)

What I need next (to catch the real “silent” case)

1) Does your pasted log cover 10:50 Cairo time?

2) Empty assistant message bubble (avatar only) in the Web UI

Very likely relevant fix in newer releases

Workaround you can try immediately (to confirm it’s Telegram streaming-related)

3) How often should you update OpenClaw?

What I need next

What happened at 08:50 (the “no reply” moment)

OpenClaw retries instead of immediately surfacing transient errors

Why did the Web UI show an empty assistant bubble then?

What I’d do next (fastest path)

A) Upgrade (strongly recommended)

B) Temporary workaround to confirm the root cause

C) Confirm whether Telegram actually received those messages

One question (to avoid guessing)

A) The “no reply” at 08:50 was Google overload, then recovery

B) The Moonshot/Kimi run is slow, not “stuck”

C) Your Control UI/WebChat connection is flapping behind your proxy

What I’d do immediately

Quick question

What the logs prove happened

1) The Kimi (Moonshot) run did not stall — it just took ~3.5 minutes

2) The Google run did error — it just recovered

Why you saw an “empty assistant bubble” in the Control UI

What to do (in order)

A) Update OpenClaw

B) Quick workaround to validate root cause: disable Telegram preview streaming

C) Fix the proxy / WS disconnects (Control UI reliability)

One key clarification

What that means in practice

Two concrete next steps that should make this sane

One question (so we don’t chase the wrong thing)

1) /reset vs /new (quick recap)

2) “Agent stops responding / empty assistant bubble” — what your logs actually show

A) You did have provider errors — OpenClaw retried, so you didn’t see an error message

B) The Moonshot/Kimi run wasn’t dead — it was just slow, then it sent a burst of chunks

C) Your Control UI connection is objectively unstable behind your proxy

3) Auto-compaction with different model context windows (your “800k” question)

What I would do next (highest leverage)

Step 1: Update OpenClaw

Step 2 (fast A/B test): temporarily disable Telegram preview streaming

Step 3: fix the reverse proxy websocket situation (Control UI)

What the logs still say, though

Your plan (update + disable streaming) is exactly right

One quick verification that will save time if this persists

Also: that “node list command” verbose message

Title

Summary

Version

Environment

Steps to reproduce (intermittent)

Expected behavior

Actual behavior

Relevant log excerpts (sanitized)

Notes / observations

Config / additional info to include (if needed)

Screenshots

Option A (recommended for your setup): allow insecure private WS for the CLI container

Option B: run the CLI inside the gateway container (no remote WS at all)

Option C: use TLS inside Docker and switch to wss://

Why Option A didn’t work (even with OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1)

If you really want Option A inside Docker

Can you re-grab a bigger slice around 19:58 UTC?

What I can already tell from what you pasted

One more important clue

The most common causes (in order)

1) Two processes are consuming the same Telegram bot updates

2) A webhook is set for that bot token

3) The Telegram poller crashed/stalled

What I need from you (minimal, high-signal)

1) Do these logs cover 10:50pm Cairo?

2) Tool-call events show up in Telegram, but the final answer is missing

1) `/reset` vs `/new` (quick recap)

Option C: use TLS inside Docker and switch to `wss://`

Why Option A didn’t work (even with `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1`)

1) Reproduce once with `/verbose off`