Telegram Group Topic Spam Response

[ivory condor]

I'm seeing repeated message sends in Telegram group chats when using a custom provider with api: "openai-completions". The model calls message(action=send) once, but the agent keeps re-entering and sending the same message with slightly different wording (3-20 times) until i force to restart the gateway

This only happens in group chat (DMs are fine) and only with openai-completions, switching the same model to ollama adapter stops the loop immediately.

I traced it to pendingPostToolCallDeltas in openai-transport-stream.ts, text arriving after tool_calls gets buffered and flushed as a trailing content block, which seems to trigger the agent to re-enter the generation loop. The ollama adapter doesn't buffer post-tool-call text, so it doesn't loop.

Is this a known issue? Any recommended workaround beyond switching to the ollama adapter?

[runic verge]

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

[solar hinge]

This looks like a real OpenAI-compatible streaming edge case, and I don’t see an already-indexed issue for that exact pendingPostToolCallDeltas / Telegram-group resend loop.

I checked current main: openai-transport-stream.ts does intentionally buffer visible text/reasoning that arrives while a toolCall block is active, then flushes it after the tool call. There’s even a regression test preserving “visible reasoning text arrives between tool-call chunks”, so the buffering itself is expected behavior. What sounds buggy is the downstream interaction: after message(action=send) succeeds, that flushed trailing assistant text can still become a deliverable block reply / continuation signal, and in group chat that can re-trigger the run. The Ollama adapter avoiding that post-tool text path explains why switching adapters stops it.

Workarounds I’d try, in order:

1. Keep using the ollama adapter for that backend if it’s otherwise compatible — it’s the cleanest workaround right now.
2. If your provider is OpenRouter-like or emits reasoning_details as visible text, set the custom model compat to avoid visible reasoning detail promotion, e.g. compat.visibleReasoningDetailTypes: []. That won’t stop plain delta.content after tool calls, but it can stop the response.output_text/response.text path.
3. Tune the upstream model/template to not emit assistant text in the same streamed completion as tool_calls — OpenAI-compatible tool streams really need “tool call only, then wait for tool result”.
4. As a containment measure for Telegram groups, restrict/deny the message tool for that group or make the group require mentions until fixed, so a loop can’t spam the room.

I’d file this as a GitHub bug with your minimal stream trace, OpenClaw version, and model/provider config: https://github.com/openclaw/openclaw/issues

The key repro artifact is: streamed tool_calls for message.send + later delta.content/visible reasoning in the same assistant turn +