Bug type

Behavior bug (inbound channel dispatch aborts before assistant run starts)

Summary

Telegram inbound dispatch can fail during reply-resolver preflight compaction when the stored Codex thread id is stale/missing. The inbound message is accepted by the Telegram channel, but dispatch exits with:

Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

No assistant run starts for that inbound message. The expected recovery would be to clear/replace the stale thread binding, start a fresh Codex thread/session path, or otherwise continue dispatch after missing-thread recovery.

This appears distinct from the general Telegram silent/hang issues because the failure is explicit and occurs before the run starts, with sessionId=unknown and source=replyResolver.

Environment

• OpenClaw version: 2026.5.22
• Install method: npm global
• Runtime: Node 22
• OS: Linux
• Channel: Telegram group
• Plugins active: browser, codex, memory-core, telegram
• Codex transport: managed app-server / embedded run path

Steps to reproduce

Exact deterministic reproduction is not yet known, but the observed sequence was:

1. A Telegram group-bound main agent accumulated a long enough conversation history to require preflight compaction.
2. The stored Codex thread id referenced by the reply resolver was no longer available.
3. A new Telegram inbound message arrived.
4. OpenClaw accepted the inbound message, then reply-resolver preflight compaction failed with thread not found.
5. Dispatch returned outcome=error; no assistant run started for that inbound.

Expected behavior

If preflight compaction hits a missing Codex thread, OpenClaw should recover instead of aborting inbound dispatch. Acceptable recovery behavior could be:

• clear the stale Codex thread binding and create a fresh thread,
• retry through the existing missing-thread recovery path,
• compact from persisted channel/session history without requiring the stale thread,
• or fall back to a clean session with a visible diagnostic.

The inbound message should not be dropped solely because the previous Codex thread id disappeared.

Actual behavior

The inbound message failed before an assistant run started. Multiple consecutive Telegram messages hit the same error until the session/runtime state was repaired or rotated.

Sanitized log examples:

<timestamp> [telegram] Inbound message telegram:group:<redacted-chat-id> -> @<bot> (group, image/jpeg, 46 chars)
<timestamp> [diagnostic] message dispatch completed: channel=telegram sessionId=unknown sessionKey=agent:main:telegram:group:<redacted-chat-id> source=replyResolver outcome=error duration=22546ms error="Error: Preflight compaction required but failed: thread not found: <codex-thread-id>"
<timestamp> [diagnostic] message processed: channel=telegram chatId=telegram:<redacted-chat-id> messageId=<redacted-message-id> sessionId=unknown sessionKey=agent:main:telegram:group:<redacted-chat-id> outcome=error duration=22643ms error="Error: Preflight compaction required but failed: thread not found: <codex-thread-id>"
<timestamp> [telegram] dispatch failed: Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

Repeated on subsequent inbound messages:

<timestamp> [telegram] Inbound message telegram:group:<redacted-chat-id> -> @<bot> (group, 16 chars)
<timestamp> [diagnostic] message dispatch completed: channel=telegram sessionId=unknown sessionKey=agent:main:telegram:group:<redacted-chat-id> source=replyResolver outcome=error duration=5115ms error="Error: Preflight compaction required but failed: thread not found: <codex-thread-id>"
<timestamp> [telegram] dispatch failed: Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

Impact

Telegram group conversations can appear broken even though the channel receives messages. The user-facing failure is a silent/non-useful failed turn: the inbound is consumed, dispatch errors, and the assistant does not answer until the stale state is repaired or rotated.

Related issues checked

I found related open issues, but none seemed to cover this exact missing-thread/preflight-compaction abort path:

• Telegram inbound dispatch hangs after Inbound message log #84710: Telegram inbound dispatch hangs after inbound log
• Telegram group message recorded into agent session but no run dispatched until next message #84154: Telegram group message recorded but no run dispatched until next message
• [Bug]: Telegram: real reply intermittently never sent; progress draft deletes anyway, leaving silent drop #85520: Telegram real reply intermittently never sent after progress draft
• [Bug]: Potential resource leak in runBoundTurnWithMissingThreadRecovery -- retry not wrapped in try/finally after thread spawn #85458: source-level concern around runBoundTurnWithMissingThreadRecovery
• [Bug]: 2026.5.22 gateway pre-warm (warmCurrentProviderAuthState) blocks event loop ~60s on startup, breaks channel handshakes #85999: provider auth prewarm blocks event loop on startup

The event-loop/prewarm behavior may be supporting context in this incident, but the actionable bug here is missing-thread recovery during reply-resolver preflight compaction.