openclaw - 💡(How to fix) Fix Bug: Model turn retry re-injects stale prompt instead of user's actual message

Summary

When a model turn fails or times out, the OpenClaw retry mechanism can re-inject a previous task prompt (e.g., a scheduled/cron task prompt) instead of the user's actual most recent message. The user's real question is lost, and the model responds to the stale prompt, making the agent appear unresponsive to the user's actual input.

Environment

• OpenClaw: 2026.5.4
• Channel: Telegram (direct)
• Model: ollama/glm-5.1:cloud

Steps to Reproduce

1. A cron/scheduled task sends a system message (e.g., [Retry after the previous model attempt failed or timed out] with a stale LobsterBlog automation prompt)
2. The user's actual question was about something completely different
3. The model picks up the retry payload (stale task) instead of the user's actual message
4. The model responds to the wrong prompt, and the user's real question goes unanswered

Observed Behavior

The retry mechanism injected a [Retry after the previous model attempt failed or timed out] message that contained a duplicate of an earlier LobsterBlog task prompt. The model then executed the blog task instead of answering the user's actual question. The user had to ask again.

Expected Behavior

When a model turn fails and is retried, the retry should use the user's actual most recent message. If the retry cannot preserve the original user message, it should fail gracefully and notify the user rather than substituting a stale prompt from a different context.

Related Issues

• #61006 — Fallback retry rewrites user prompt into synthetic "Continue where you left off" string (same root concern: retry corrupts the user's intended prompt)
• #55181 — Duplicate user message injection on rotate_profile retry loop
• #43482 — Fallback retry should detect partial tool execution before replaying prompt
• #48400 — Session JSONL loses tool call entries after auto-retry of overloaded_error
• #61479 — Subagent completion announce retry re-injects duplicate internal-context turns

Root Cause (Suspected)

The retry infrastructure (resolveFallbackRetryPrompt / runEmbeddedAttempt path) appears to reconstruct the turn prompt from the session transcript rather than preserving the user's actual inbound message. When a prior turn's prompt (e.g., a cron task) is still in the transcript, it can be picked up by the retry logic instead of the user's most recent message.

Suggested Fix

The retry path should pin to the user's actual inbound message ID/content rather than reconstructing from the session transcript. If the original user message cannot be recovered, the retry should fail with a visible error rather than substituting a different prompt.