[BUG] Message Fails to Be Added to Queue When Command is Running

[johnameyer]

Problem (one or two sentences)

Submitting a message (by enter or by pressing the send button) while a command is running fails to enqueue the message. Instead the message completely disappears and the "proceed while running" and "kill command" buttons become greyed out.

Context (who is affected and when)

Should affect anyone submitting a message while a command is being run.

Reproduction steps

1. MacOS, VSCode extension
2. Prompt Roo to do something that takes a while i.e. "Run sleep 60"
3. Type a clarifying message to queue up
4. Click the send button or press enter
5. Message disappears
6. Subsequent messages are sent successfully

Expected result

The message is queued up

Actual result

The message disappears completely from the text space but does not show in the queue

Variations tried (optional)

No response

App Version

3.39.3

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause Analysis

When a command is running (the command_output state), the UI shows "Proceed While Running" and "Kill Command" buttons. At this point:

• sendingDisabled is set to false
• clineAsk is set to "command_output"
• enableButtons is true

When a user types a message and presses Enter, the queueing condition in handleSendMessage checks:

if (sendingDisabled || isStreaming || messageQueue.length > 0) {
    // Queue the message
}

Since sendingDisabled is false during command_output, and if isStreaming is also false (no API request in flight) and the queue is empty, the message is not queued. Instead, it's sent directly as an askResponse: "messageResponse".

Immediately after, handleChatReset() is called, which:

• Sets sendingDisabled = true
• Clears clineAsk
• Sets enableButtons = false

This grays out the buttons even though the command is still running. The message "disappears" because it's sent as feedback to the command (stored for later display when the command completes), not queued for the message queue UI.

Proposed Fix

Modify the queueing condition in handleSendMessage to also queue messages when command_output is the current ask state:

// Queue message if:
// - Task is busy (sendingDisabled)
// - API request in progress (isStreaming)
// - Queue has items (preserve message order during drain)
// - Command is running (command_output)
if (sendingDisabled || isStreaming || messageQueue.length > 0 || clineAskRef.current === "command_output") {
    // Queue the message
    ...
}

This ensures that when a command is running, messages typed by the user are properly queued (and displayed in the queue UI) rather than being sent as feedback that disappears. The user can still interact with the running command through the "Proceed While Running" and "Kill Command" buttons.

I'll also add a test case to verify this behavior.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[johnameyer]

@roomote What do you mean by "it's sent as feedback to the command (stored for later display when the command completes)"? I don't see the message pop up once the command completes or see my note be acknowledged by the agent.

[roomote]

Thanks for the follow-up question! You're right to call that out - I need to investigate the code more closely to understand exactly what happens to the message when it's sent during command execution. I'll dig into the message handling flow and provide a more accurate explanation along with a fix. Will open a PR to share my findings and proposed solution.

[roomote]

Thanks for the follow-up question! You're right that the current behavior is confusing.

I've investigated this issue and found the root cause: when a command is running (command_output state), user messages were being sent as direct askResponse messages instead of being queued. Because the backend is waiting for terminal feedback during command execution, these user messages were effectively being ignored/lost.

I've opened a draft PR with a fix: #10677

The fix adds clineAsk === "command_output" to the message queue condition, so messages sent during command execution are now queued and will be processed once the command completes (or is cancelled).

Feedback welcome!

[johnameyer]

@roomote What is "askResponse" used for? Does changing that behavior break some other workflow?

[roomote]

Great question! Let me explain how askResponse works and why the fix is safe.

What is askResponse?

askResponse is the communication mechanism between the webview (UI) and the extension (backend) for user interactions. When the backend needs user input, it calls task.ask(type, ...) which blocks until a response arrives. The webview sends responses via vscode.postMessage({ type: "askResponse", askResponse: "...", ... }).

There are 4 types:

• messageResponse: User sent a text message
• yesButtonClicked: User clicked an approve/yes button
• noButtonClicked: User clicked a reject/no button
• objectResponse: Batch file responses (e.g., for file uploads)

The Bug Scenario

During command_output:

1. Backend calls task.ask("command_output", ...) which blocks waiting for terminal events OR user response
2. UI sets clineAsk = "command_output" and shows "Proceed While Running" / "Kill Command" buttons
3. If user types a message and presses Enter, it was sent as askResponse: messageResponse
4. This unblocks the ask() in Task.ts, but the code path after ask("command_output") expects terminal-related responses, not user messages
5. The message effectively gets lost

Does the Fix Break Other Workflows?

No, because:

1. Button clicks are handled separately: "Proceed While Running" and "Kill Command" use terminalOperation messages (see ChatView.tsx lines 729, 780), not askResponse. The fix doesnt affect these.

2. Only command_output is affected: The fix adds clineAsk === "command_output" to the queue condition, so only typed messages during running commands get queued. All other ask types (tool, followup, completion_result, etc.) continue working as before.

3. Queued messages are processed appropriately: Messages in the queue are dequeued and processed at appropriate times (after ask() returns or when the command completes/is cancelled).

The fix in PR #10677 ensures that when a command is running, user messages are queued instead of being sent directly as askResponse, where they would be lost.

[johnameyer]

@roomote with your change, does the message still "unblock" the ask / disable the buttons?

[roomote]

Great question! No, with the fix, the message no longer unblocks the ask or disables the buttons.

Here's the difference:

Before the fix:
When you sent a message during command_output, it went through the askResponse path, which then called handleChatReset(). This function:

• Set sendingDisabled = true
• Set clineAsk = undefined
• Set enableButtons = false

So the buttons got disabled and the ask was "unblocked" (even though the message was lost).

With the fix:
The message now goes through the queueMessage path instead. This path does NOT call handleChatReset(), so:

• Buttons remain enabled
• clineAsk stays as "command_output"
• User can still click "Proceed While Running" or "Kill Command"

This is actually the intended behavior! Users can now:

1. Type a message while a command is running (queued for later)
2. Continue interacting with the running command via the buttons
3. Have their queued message processed once the command completes or they click a button

The PR ensures the message is preserved (queued) without disrupting the current UI state for the running command.