Bug type

Behavior bug (incorrect output/state without crash)

Summary

On WhatsApp direct (1:1), sending an image to the main agent wedges the message lane for ~3 minutes before any real processing of the prompt starts. The inbound image is injected as a native multimodal image block into the main agent's run, so the run that ingests it is itself an embedded_run. When that run reaches run:completed, its active-reply marker is not cleared: the lane stays state=processing with reason=queued_work_without_active_run, and the stuck-session recovery skips with active_reply_work (action=keep_lane) for ~3 min before finally escalating to abort_embedded_run and releasing the lane. Only after that does the agent route the request to a worker.

This is the same reason-code signature as the canonical follow-up-drain race #91909 (queued_work_without_active_run → keep_lane/active_reply_work → abort_embedded_run), which was closed as fixed by #95039. However:

• The installed build 2026.6.10 (aa69b12d) already contains fix(queue): restart dormant followup drains #95039 (merge commit 023993249f..., behind_by=0), yet this still reproduces.
• [Bug]: Inbound dispatch race: queued message after run completion never starts a new run (queued_work_without_active_run), agent goes silent until stuck-session watchdog fires #91909 is described as a general race triggered by a fast (~1–2 s) text follow-up on Slack threads. This report is a distinct trigger: an inbound image (multimodal block) on a WhatsApp 1:1 lane, and the lane wedged here without a rapid user follow-up — the queue grew while the user was idle, behind a multimodal embedded_run that never cleared.

Filing as a focused, image/multimodal-specific variant and cross-referencing #91909 / #95039 so maintainers can either fold it into the canonical tracker or treat it as a surviving variant of the same race.

Environment

• OpenClaw 2026.6.10 (aa69b12d), self-hosted Linux, systemd user gateway, loopback bind
• Channel: WhatsApp direct (1:1)
• messages.visibleReplies=automatic
• Main agent model: gpt-5.5
• Queue mode: default (steer)
• openclaw tasks list: 0 queued · 0 running · 0 issues during the wedge (the wedge is invisible to the task subsystem)

Steps to reproduce

1. In a WhatsApp direct chat, send the main agent an image (no caption / "what is this?" style).
2. The agent receives the image as a native multimodal block, replies once (e.g. a clarifying question), and the run reaches run:completed.
3. Observe: the lane stays processing; subsequent inbound (and internal queue work) does not start a new run.
4. ~3 min later the stuck-session watchdog fires and abort_embedded_run releases the lane; only then does real routing/processing begin.

Observed log evidence (BRT timestamps)

13:37:18  inbound image (no caption) -> injected as native multimodal image block into main's run
13:37:26  main replies (text), run:completed ~13:37:27

13:40:36  WARN stuck session: sessionKey=agent:main:whatsapp:direct:+<redacted>
          state=processing age=136s queueDepth=5
          reason=queued_work_without_active_run classification=stale_session_state
          lastProgress=run:completed lastProgressAge=189s terminalProgressStale=true recovery=checking

13:40:36 .. 13:43:35  (repeated)
          stuck session recovery outcome: status=skipped action=keep_lane
          activeSessionId=<same> activeWorkKind=embedded_run reason=active_reply_work

13:43:51  stuck session recovery outcome: action=abort_embedded_run   -> lane released
13:43:52+ queued messages finally processed; main then spawns the worker correctly

Trajectory confirms the inbound image was present in the model context as a type:image multimodal block (no separate vision/OCR tool call) — i.e. the wedging embedded_run is the main agent's own multimodal run, not a Codex app-server / subprocess (distinguishing this from the Codex-embedded-runner reports #85251 / #85532).

Expected

Receiving an image on a 1:1 lane should not strand the lane. Either the multimodal run's active-reply marker must be cleared on run:completed so the followup drain can start, or recovery must treat lastProgress=run:completed + terminalProgressStale=true as authoritative over a stale embedded_run active_reply_work marker and release the lane immediately instead of waiting ~3 min.

Related

• [Bug]: Inbound dispatch race: queued message after run completion never starts a new run (queued_work_without_active_run), agent goes silent until stuck-session watchdog fires #91909 (canonical follow-up-drain race; queued_work_without_active_run) — closed as fixed by fix(queue): restart dormant followup drains #95039
• fix(queue): restart dormant followup drains #95039 (the fix, present in 2026.6.10) — this report reproduces after it
• Group session lane wedges indefinitely: stuck-recovery skips with active_reply_work false positive #85639 (group-session active_reply_work false-positive wedge; closed) — same skip reason, different channel