[BUG] It runs non-approved commands by itself if I have queued messages!

[Alexey-Akishin]

Problem (one or two sentences)

I noticed if I have a queued message, and the LLM happens to generate command, even if it is a command that normally asks for approval and waits, it just runs it! This is surely a bug, because if I do not have queued message, but send a message normally as a reply to a request to approve a command, but without pressing approve, just the send button, the command gets rejected. Naturally, sending queued message also should reject any command that is not explicitly in auto-approve list or if I have Execute auto-approve disabled!

Context (who is affected and when)

This is obviously very dangerous - it can run npm / yarn packages that I prefer to run in separate user account for security (against supply chain attacks), it can also run arbitrary python script, delete files, run a chain of commands like "git add -A" followed by git commit adding lots of untracked files, etc. I was very careful to only enable auto approval for commands I actually want, so it absolutely should not run one that I did not explicitly approved just because there were queued message!

I already got burned by this quite a few times, every single time LLM comes up with a command when I have a message queued, it is something I did not expect or did not want to run at all.

Reproduction steps

1. Make the LLM do some work, and send a queued message
2. If LLM decides to request a command to run, and there is a queued message, the queued message gets sent and approves the arbitrary command even if it was not explicitly in auto-approved list and normally would ask for approval, while expected behavior in such a case is to auto-refuse (since this is what happens if I send a message in response normally without pressing Approve - the unapproved command gets refused).

Expected result

If I had queued message, it gets sent and unapproved commands gets refused - only exception if the command was explicitly in my auto-approve list and Execute autoapproval was enabled

Actual result

The command that normally would request approval without queued message, gets unexpectedly executed, possibly wrecking havoc

Variations tried (optional)

No response

App Version

Latest git

API Provider (optional)

OpenAI Compatible

Model Used (optional)

Kimi K2.6

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and found the root cause. Here's my proposed implementation plan:

Root Cause

In src/core/task/Task.ts, when a queued message is drained during a command, tool, or use_mcp_server ask, the code unconditionally sends "yesButtonClicked" (lines 1437 and 1462), which approves the tool/command regardless of auto-approval settings.

The flow is:

1. checkAutoApproval() runs (line 1366) and returns { decision: "ask" } for commands not in the auto-approve list
2. Since decision is "ask", approveAsk() is NOT called (lines 1368-1380), so the task blocks waiting for user input
3. But the queued message drain code at line 1429-1443 (and again at 1456-1465 inside the pWaitFor poll) bypasses this check and sends "yesButtonClicked" unconditionally -- effectively auto-approving any command just because a message was queued

This is the same as clicking the "Approve" button, which is clearly wrong for commands the user never approved.

Proposed Fix

Change the queued message drain behavior for tool/command/use_mcp_server asks to send "messageResponse" instead of "yesButtonClicked". This matches the behavior when a user manually types a message without clicking the Approve button (the command gets rejected, which is the expected behavior described in the issue).

Specifically, two locations in src/core/task/Task.ts:

1. Line 1437: Change this.handleWebviewAskResponse("yesButtonClicked", message.text, message.images) to this.handleWebviewAskResponse("messageResponse", message.text, message.images)

2. Line 1462: Same change inside the pWaitFor callback

This means when a queued message is drained:

• Commands/tools that were already auto-approved (decision="approve") will have been resolved before reaching this code, so they are unaffected
• Commands/tools that need user approval (decision="ask") will be rejected, and the queued message text will be sent as a regular message -- matching the behavior of typing a reply without clicking Approve

Tests: Update the existing test in src/core/task/__tests__/ask-queued-message-drain.spec.ts to verify that queued messages reject unapproved commands rather than approving them.

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

[Alexey-Akishin]

@roomote The plan sounds good, thanks! Looking forward to a fix!

[roomote-v0]

Thanks for the feedback, @Alexey-Akishin! I've seen your comment and will proceed with the fix. I'll open a PR to share progress shortly.

[roomote-v0]

Opened a draft PR with my attempt at addressing this: #12303. Feedback welcome!