openclaw - 💡(How to fix) Fix OpenClaw TUI busy input lock prevents queueing prompts, unlike Telegram

Area

OpenClaw TUI

Problem

When an agent is running in the OpenClaw TUI, the input area shows:

agent is busy — press Esc to abort before sending a new message

At this point, the user cannot submit another prompt. This means the prompt cannot enter OpenClaw's queue system at all.

Expected behavior

While an agent is busy, the TUI should allow the user to submit a new prompt and let OpenClaw handle it according to queue behavior, for example:

• queue it for the next turn
• interrupt the current run
• steer/append instructions if supported

Actual behavior

The TUI blocks submission before the message enters OpenClaw. The user has to type a follow-up prompt and wait with it sitting in the input box until the current run finishes.

Difference from Telegram

In Telegram, I can continue typing and sending messages while the agent is busy. Those messages can still enter OpenClaw and be handled asynchronously.

In the OpenClaw TUI, however, submission is blocked by the busy input lock before the message enters OpenClaw. This makes the TUI behavior different from Telegram and prevents the queue mechanism from being useful there.

Why this matters

For long-running tasks, this prevents async workflow. The user cannot leave follow-up instructions in advance and step away.

What I tried

• Tested messages.queue.mode=steer
• Tested messages.queue.mode=interrupt
• Returned messages.queue to default / removed custom queue settings
• Gateway was running and connectivity probe was OK

Current understanding

steer, interrupt, and collect appear to apply only after a message enters OpenClaw. The TUI busy lock prevents the message from entering the queue in the first place.

Request

Please clarify whether the TUI busy input lock is intentional. If queueing prompts during a running agent is intended to be supported, the TUI should allow prompt submission while busy, or provide a setting to enable it.