openclaw - 💡(How to fix) Fix [Bug]: Telegram: real reply intermittently never sent; progress draft deletes anyway, leaving silent drop

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

On 2026.5.20, Telegram replies intermittently fail to send: the tool-progress draft displays correctly and the underlying tool action completes successfully, but the real reply message is never sent and the progress draft is then deleted on schedule, leaving the user with no visible bot response.

Steps to reproduce

1. Install openclaw 2026.5.20 from npm on macOS with Node 24.
2. Configure the Telegram channel with a bot token and a single allowed direct chat.
3. Configure the codex plugin with appServerTransport=stdio, appServerCommandSource=managed, authProfileId=openai:default.
4. Send any inbound Telegram message to the bot from the allowed chat.
5. Observe whether the bot's real reply is sent. Failure occurs intermittently; observed three times across roughly 36 hours on the same install. No deterministic content, length, or timing trigger has been identified; failing messages have ranged from 42 to 14,549 characters. Failing and successful turns share the same sessionId, sessionKey, and codex plugin eligibility payload.

Expected behavior

For each inbound Telegram message: (1) the bot sends a tool-progress draft (e.g. "Shelling • I'm replying..."); (2) the bot sends the actual reply text as a separate message; (3) the progress draft is deleted. This three-step pattern is observed working correctly on most turns during the same session.

Actual behavior

On affected turns: the tool-progress draft is sent and is visible to the user, then the progress draft is deleted on schedule, but no real reply message is ever sent. The underlying tool action completes successfully (e.g. folder creation on disk). Gateway logs show the inbound message, the "codex plugin thread config eligibility" log line, then no further log entries from any subsystem — no telegram outbound send, no error, no traceId, no watchdog warning — for between 58 and 1058 seconds until the next inbound message or background heartbeat. Three confirmed occurrences: 2026-05-21 18:59:11 EDT (42-char inbound), 2026-05-21 23:38:33 EDT (14,549-char inbound), 2026-05-22 00:28:48 EDT (70-char inbound).

OpenClaw version

2026.5.20

Operating system

macOS (Mac mini)

Install method

npm (project dependency)

Model

openai/gpt-5.4-mini (thinking=medium, fast=off)

Provider / routing chain

openclaw -> embedded codex app-server (stdio, managed) -> openai/gpt-5.4-mini via openai:default auth profile

Additional provider/model setup details

Standard managed Codex app-server configuration with no custom command override (OPENCLAW_CODEX_APP_SERVER_BIN not set, OPENCLAW_CODEX_APP_SERVER_ARGS not set). No project-level openclaw config block in package.json. Auth profile uses OpenAI API key mode.

Logs, screenshots, and evidence

Gateway log excerpts for the three confirmed silent-drop events:

Event 1 — 2026-05-21 18:59 EDT
[18:58:38] telegram outbound send ok messageId=82
[18:59:11] Inbound message telegram:<chatId> -> @Feesha_bot (direct, 42 chars)
[18:59:13] codex plugin thread config eligibility
[no further log entries from any subsystem for 81 seconds]
[19:00:34] Inbound message telegram:<chatId> -> @Feesha_bot (direct, 47 chars)
[19:00:36] codex plugin thread config eligibility
[19:00:51] telegram outbound send ok messageId=87

Event 2 — 2026-05-21 23:38 EDT
[23:33:04] telegram outbound send ok messageId=105
[23:38:33] Inbound message telegram:<chatId> -> @Feesha_bot (direct, 14549 chars)
[23:38:35] codex plugin thread config eligibility
[no further log entries from any subsystem for 58 seconds]
[23:39:33] Inbound message telegram:<chatId> -> @Feesha_bot (direct, 17 chars)
[23:39:35] codex plugin thread config eligibility
[23:39:40] telegram outbound send ok messageId=113

Event 3 — 2026-05-22 00:28 EDT
[00:28:48] Inbound message telegram:<chatId> -> @Feesha_bot (direct, 70 chars)
[00:28:50] codex plugin thread config eligibility
[no further log entries from any subsystem for 1058 seconds until background heartbeat]

Eligibility payload comparison (failures vs. successes):
All three failures and 8 sampled successes share identical eligibility JSON:
  enabled: false
  policyConfigured: false
  policyEnabled: false
  sessionKey: agent:main:telegram:direct:<chatId>
  appCacheKeyFingerprint: sha256:0a238cfdc074c7ee (identical across all)
  authProfileId: openai:default
  appServerTransport: stdio
  appServerCommandSource: managed

At least one successful turn (S8) used the same sessionId as all three failures, confirming that sessionId is not the discriminant.

Code-path location of the eligibility log emission:
  node_modules/openclaw/dist/run-attempt-Dhu92fNM.js (function: runCodexAppServerAttempt)
  Continues into node_modules/openclaw/dist/thread-lifecycle-CwdqyJ0h.js (function: startOrResumeThread)

Full structured JSONL logs, per-session trajectory files (.trajectory.jsonl and .jsonl session-reset artifacts) for sessionId cc9fc78d-88e5-442c-910c-0b03acc53977, and screenshots of the user-visible Telegram dissolve animation on a successful turn are available on request, with PHI/clinical-content redaction.

Impact and severity

Affected: Telegram channel users on openclaw 2026.5.20. Severity: Medium (the underlying tool action completes correctly, but the user receives no reply confirming success or providing the agent's response). Frequency: Intermittent. 3 confirmed occurrences across ~36 hours on a single active chat. Consequence: Users cannot rely on the bot's visible reply as confirmation of task completion; user must verify outcomes by inspecting the affected system directly (filesystem, vault, etc.).

Additional information

Regression tracking: NOT_ENOUGH_INFO. This is a fresh install on 2026.5.20; the bug was observed from the first day of use. No prior version was tested on this system.

Other context that may help triage:

The failure signature has notable adjacency to recent changelog entries that touch the same code area:

• 2026.5.4: "Telegram: ... keep reply-dispatch provider chunks behind a real stable runtime alias during in-place package updates."
• 2026.5.5: "Telegram/Codex: keep message-tool-only progress drafts visible and render native Codex tool progress once per tool instead of duplicating item/tool draft lines."
• Several entries about stale reply lanes, missing turn/completed, releasing session lanes when downstream consumers throw, and preventing malformed media turns from wedging gateway lanes.

The pattern looks adjacent to — but possibly distinct from — these already-patched cases.

Ruled out during diagnostic investigation:

• Eligibility-gate behavior (failures and successes share identical eligibility payloads)
• Telegram send failure (no outbound attempt logged on failing turns)
• Watchdog/timeout path (no terminal-event warnings)
• Context overflow / token / stdio buffer (no related errors)
• Workspace Git lock interference (~/.openclaw/workspace/.git has one initial commit, no activity near failures)
• Project-side code (failures occur upstream of any project tool execution)

User-visible behavior detail: On successful turns, the three-step pattern is clearly visible: (1) tool-progress draft message is sent, (2) real reply is sent as a separate message, (3) progress draft is deleted with Telegram's standard dissolve animation. On failing turns, steps 1 and 3 occur, but step 2 does not — leaving the user watching the progress draft dissolve into nothing.