openclaw - 💡(How to fix) Fix Surface whether a busy message was steered or queued as a follow-up [3 comments, 2 participants]

[!NOTE] Correction: the related stale-docs issue (#83869) was drafted from stale local docs evidence, not a fresh hosted-docs fetch. Current hosted docs already describe steer as the default. This issue is specifically about the remaining UX/diagnostics gap: making it visible whether a busy message was steered into the active run or deferred/fell back to follow-up.

Summary

Even when OpenClaw successfully steers a busy-time message into the active run, the user-facing experience can still look like ordinary queueing unless the surface shows what happened.

This contributes to the perception that OpenClaw only has "queue message" behavior and no real active-run steering.

It would help if chat/control surfaces and diagnostics clearly distinguished:

• steering accepted into the active run
• steering unavailable, falling back to follow-up
• explicit follow-up/collect queueing
• interrupt mode

Current behavior

Current source does track this distinction internally:

• queueEmbeddedPiMessageWithOutcomeAsync() returns an outcome with queued: true or structured failure reasons.
• Failure reasons include no_active_run, not_streaming, compacting, source_reply_delivery_mode_mismatch, transcript_commit_wait_unsupported, and runtime_rejected.
• Native Codex app-server steering sends turn/steer and can reject same-turn steering in review/manual compaction turns.
• /steer <message> replies with "steered current session." on explicit success and falls back to a normal prompt if steering is unavailable.

But for normal inbound busy messages, a successful steer can be nearly invisible from the user's perspective. If steering fails and the message becomes a later prompt, that can also be hard to distinguish unless verbose diagnostics are inspected.

User impact

Users trying to understand or debug busy-run behavior cannot easily answer:

• Did my message steer the current run?
• Did it get deferred as a follow-up?
• Did the runtime reject steering because it was compacting/reviewing/not streaming?
• Is /queue steer working for this channel/runtime?

When this is ambiguous, external comparisons describe OpenClaw as "queue only" even when the runtime did accept steering.

Suggested fix

Add a user-visible or operator-visible status signal for busy messages.

Possible implementation options:

1. Control UI / TUI

   • Show a queued item state such as Steered, Queued follow-up, or Steer fallback.
   • If a fallback happens, include the structured reason in details/tooltip.

2. Messaging channels

   • Keep default chat noise low, but expose an optional concise acknowledgement via existing verbose/status settings.
   • Example:
     • Steered current run.
     • Queued after current run: steering unavailable while compacting.

3. Diagnostics/logs

   • Emit one consistent structured event for:
     • active_run_steer_accepted
     • active_run_steer_rejected
     • followup_enqueued
   • Include session id, channel, queue mode, runtime family, and reason.

4. /queue status

   • If this command already exists, include the current busy-message mode and the last busy-message outcome.
   • If not, consider a small status line in /queue help output.

Acceptance criteria

• A user or operator can tell whether a busy message was steered into the active run or deferred for a later turn.
• Steering fallback reasons are visible somewhere practical without reading source.
• The signal works for both Pi active-run steering and native Codex app-server turn/steer.
• Default chat behavior remains low-noise, or any new chat acknowledgement is behind an existing verbose/status setting.
• Tests cover at least:
  • accepted steer
  • steer rejected/fallback
  • explicit follow-up/collect mode

Labels

Suggested labels:

• enhancement
• ui
• tui
• gateway
• agents
• extensions: codex