openclaw - 💡(How to fix) Fix [Bug]: Telegram partial streaming receives no assistant deltas for openai-codex; newline chunking only sends final blocks

Summary

Telegram partial streaming with chunkMode: "newline" no longer shows the assistant reply building up live for an openai-codex/gpt-5.5 agent. Telegram only receives a completed answer block near the end of the turn.

I instrumented the Telegram streaming path and found that onPartialReply is not receiving any assistant text deltas for this provider path. Telegram's draft stream does send the final text, but there are no intermediate preview.edit updates and no partial.raw events.

Environment

• OpenClaw: 2026.5.26 stable, release branch commit 965ef470fb
• Latest stable found while checking: v2026.5.27; I did not find a merged issue/PR in that line that appears to address this exact path
• Install: Docker Compose, Linux VPS
• Channel: Telegram group/topic and Telegram DM
• Provider/model: openai-codex/gpt-5.5 via ChatGPT/OAuth, not billable API key
• Telegram config:

{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "partial",
        "chunkMode": "newline",
        "preview": {
          "toolProgress": true,
          "commandText": "status"
        },
        "progress": {
          "toolProgress": true,
          "commandText": "status"
        }
      }
    }
  },
  "messages": {
    "suppressToolErrors": true
  }
}

Expected behavior

With Telegram streaming mode partial and chunkMode: "newline", the Telegram reply should visibly update as the assistant produces answer text, or at least emit newline-sized partial chunks during the turn.

This used to be the user-visible behavior in older 2026.4.x builds in this environment: the Telegram message could be watched while it was being constructed.

Actual behavior

Telegram receives only a complete answer block near the end of the turn. The user cannot watch the reply prose build up.

Control UI can still show runtime/tool activity, so the gateway is alive and the turn is progressing. The missing piece is assistant-answer deltas reaching the Telegram onPartialReply/draft-stream path.

Trace evidence

I temporarily added diagnostic logs at these points:

• extensions/telegram/src/bot-message-dispatch.ts: log every onPartialReply callback as [telegram-stream-trace] partial.raw
• extensions/telegram/src/draft-stream.ts: log preview.update, preview.attempt, preview.send, and preview.edit

Three real Telegram test turns showed the same pattern:

Test 1, long answer
17:50:57 UTC inbound Telegram message
17:51:04 UTC [telegram-stream-trace] preview.update textLen=452 final=true
17:51:04 UTC preview.send
(no partial.raw)
(no preview.edit)

Test 2
17:58:25 UTC inbound Telegram message
17:59:19 UTC [telegram-stream-trace] preview.update textLen=160 final=true
17:59:19 UTC preview.send
(no partial.raw)
(no preview.edit)

Test 3, longer answer
18:01:01 UTC inbound Telegram message
18:01:12 UTC [telegram-stream-trace] preview.update textLen=1408 final=true
18:01:12 UTC preview.send/final delivery
(no partial.raw)
(no preview.edit)

So Telegram is not receiving many small deltas and failing to edit them. It receives a single completed/final text update.

Source-level hypothesis

From reading the current source:

• extensions/telegram/src/bot-message-dispatch.ts does wire onPartialReply into the Telegram draft stream path.
• extensions/telegram/src/draft-stream.ts can send/edit draft previews.
• src/auto-reply/reply/agent-runner-cli-dispatch.ts bridges agent events with stream: "assistant" into onAssistantText, then to onPartialReply.
• src/agents/cli-runner/execute.ts emits those assistant events when the CLI JSONL streaming parser produces deltas.
• src/agents/cli-output.ts / createCliJsonlStreamingParser() appears to parse Claude-style stream-json deltas via parseClaudeCliStreamingDelta() gated by usesClaudeStreamJsonDialect(...).

I could not find an equivalent openai-codex JSONL/app-server assistant-delta parser path that emits stream: "assistant" events for live final-answer prose. That matches the trace: Telegram is wired correctly, but no openai-codex assistant deltas arrive at that seam.

One smaller config/documentation footgun: chunkMode: "newline" appears to affect final text splitting, not live draft update frequency. The current behavior makes the setting look ineffective for openai-codex Telegram partial streaming.

Related but not exact duplicates checked

• #87072 — opt-in interleaved progress lane. Helpful adjacent PR, but by design it streams reasoning/tool progress only; the final answer prose is still delivered once as the polished answer. It does not fix missing onPartialReply assistant deltas.
• #79681 — Telegram typing indicator keepalive regression. Adjacent UX, not assistant text streaming.
• #85765 — Anthropic thinking blocks ordering/coalescing. Different provider/path.
• #84516 — Codex app-server long replies truncated. Different symptom.
• #80458 — phase-tagged commentary leaking into channels. Different symptom, same provider family.
• #80520 — Telegram messages silently dropped. Different symptom.

Suggested fix

Add openai-codex assistant-delta support at the CLI/app-server event bridge layer so live assistant answer text emits stream: "assistant" events and reaches onPartialReply.

A regression test could cover:

1. A simulated openai-codex streaming turn emits assistant text deltas.
2. agent-runner-cli-dispatch forwards them to onPartialReply.
3. Telegram draft stream receives multiple non-final updates before final delivery.
4. chunkMode: "newline" either applies to draft updates or docs/config clearly state it only affects final splitting.

If maintainers prefer answer prose not to live-stream for codex, then the docs/config should say that Telegram partial only covers progress/reasoning for this provider path, not the final answer text.