TUI sendMessage blocks messages with "agent is busy" regardless of /queue mode setting

Summary

The TUI client (src/tui/tui-command-handlers.ts) hardcodes a busy check in sendMessage() that blocks new messages when the agent is running, completely ignoring the /queue mode setting configured on the Gateway. This means followup, collect, and interrupt modes do not work from the TUI.

Steps to Reproduce

1. Start OpenClaw Gateway and open the TUI (openclaw tui)
2. Send a message that takes a while to process (or trigger a long tool execution)
3. While the agent is running, run /queue mode=followup
4. Send another message

Expected: The message is sent to the Gateway. The Gateway queues it as a followup turn (per the queue documentation), which executes after the current run ends.

Actual: TUI immediately shows agent is busy — press Esc to abort before sending a new message and does not send the message to the Gateway at all. The queued followup never fires because the message was blocked at the TUI layer.

Root Cause

In src/tui/tui-command-handlers.ts, the sendMessage function (around line 660) has a hardcoded busy check:

const busy = Boolean(
  state.activeChatRunId || state.pendingChatRunId || state.pendingOptimisticUserMessage,
);

if (
  !isBtw &&
  (state.pendingChatRunId ||
    state.pendingOptimisticUserMessage ||
    (opts.local !== true && state.activeChatRunId))
) {
  chatLog.addSystem("agent is busy — press Esc to abort before sending a new message");
  tui.requestRender();
  return;  // ← exits without sending to Gateway
}

This check:

1. Blocks the message at the TUI layer — it never reaches the Gateway's queue system
2. Does not read or respect any /queue mode setting — the TUI doesn't even know what mode is set
3. Only allows stop commands (/stop or Esc) to proceed

The same check also appears in the top-level isRunning guard (line 109):

const isRunning = Boolean(state.activeChatRunId || state.pendingChatRunId || state.pendingOptimisticUserMessage);

Why This Is a Bug

The Gateway correctly implements all four queue modes (steer, followup, collect, interrupt) as documented in docs/concepts/queue.md. But the TUI intercepts messages before they can reach the Gateway, making these settings unusable from the TUI.

The TUI should either:

1. Let the Gateway decide — send the message and let the Gateway's queue mode handle it (same behavior as WebChat)
2. Or — at minimum, respect the current queue mode when deciding whether to show the busy message

Environment

• OpenClaw version: 2026.5.28 (commit 1a721b5679)
• TUI running on macOS arm64
• Model: bailian/qwen3.6-plus
• /queue mode: followup (confirmed set on session)

Related

• Queue documentation — describes the 4 modes that TUI bypasses
• Queue steering — how followup/collect/interrupt should work at runtime boundaries
• CHANGELOG.md:109 — "TUI/status: queue prompts submitted while an agent is busy" — suggests this was an intentional feature but the implementation blocks at TUI level rather than letting Gateway handle it

Suggested Fix

Remove or gate the busy check in sendMessage() so messages are forwarded to the Gateway, and let the Gateway's queue system handle them according to the configured mode. If a UX indicator is needed, show a visual cue that the message will be queued rather than blocking it entirely.