[BUG] Edited message vanishes upon resending during pending tool approval, leading to empty API request and UI hang

[wangqiang2512-lab]

Problem (one or two sentences)

After editing and resending an instruction while a tool call is pending, the new message completely disappears from the chat history. The system triggers an API request that never returns a result, and the UI remains stuck on the previous assistant response.

Context (who is affected and when)

This happens to any user who realizes they made a mistake in their instruction and tries to use the "Edit" button to fix it while Roo Code is in the middle of a task (specifically when waiting for the user to click "Approve/Reject" for a tool call). Instead of starting over with the new instruction, the user sees their updated message disappear and the interface get stuck on the old conversation state.

Reproduction steps

1. Send a task that results in a tool approval request (e.g., "Read file X").
2. While the "Approve/Reject" buttons are visible, click the Edit icon on your original prompt.
3. Modify the text and click the "Resend" button.
4. Observe: The edited message does NOT appear in the chat. The previous message's response remains as the last item.
5. Observe: An "API Request..." spinner appears but eventually yields no response, leaving the task in a broken state.

Expected result

The chat history should update with the new edited message, the previous pending tool call should be cancelled, and the assistant should provide a new response based on the updated text.

Actual result

The edited instruction is lost (never rendered in chat). The API call is triggered with no context/content, and the UI stays frozen on the buttons/options of the prior response.

Variations tried (optional)

No response

App Version

v3.45.0

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

Proposed Implementation Plan

Root Cause Analysis

After investigating the codebase, I identified the root cause of this bug:

1. The Flow When Bug Occurs:

   • Task calls ask() for tool approval (e.g., "tool", "command", "browser_action_launch")
   • ask() in Task.ts uses pWaitFor to block until this.askResponse !== undefined || this.lastMessageTs !== askTs
   • While waiting, user clicks edit on a previous message
   • handleEditMessageConfirm processes the edit, truncates history, and calls currentCline.submitUserMessage(editedContent, images)
   • submitUserMessage calls handleWebviewAskResponse("messageResponse", text, images)

2. The Problem:

   • The pending ask() was waiting for a tool approval response (yes/no), but receives "messageResponse" instead
   • The pWaitFor condition is satisfied because askResponse !== undefined, so the ask completes
   • However, the edited message text gets consumed by the wrong ask handler
   • The task state becomes inconsistent and the UI hangs

Proposed Fix

Modify handleEditMessageConfirm in webviewMessageHandler.ts to:

1. Cancel any pending request before processing the edit:

   • Call cancelCurrentRequest() to abort any ongoing API streaming
   • Reset the ask-related state variables (askResponse, askResponseText, askResponseImages)

2. Start a fresh task loop:

   • Instead of calling submitUserMessage (which responds to an existing ask), the edit should initiate a new task loop
   • Use initiateTaskLoop() or similar mechanism to start fresh with the edited message

Implementation Details

File: src/core/webview/webviewMessageHandler.ts

• In handleEditMessageConfirm, before calling submitUserMessage:
  • Check if there is a pending ask (tool approval) waiting
  • If so, cancel it and reset the task state
  • Then initiate a fresh conversation loop with the edited message

File: src/core/task/Task.ts

• May need to expose a method to properly cancel a pending ask and reset state
• Alternatively, modify submitUserMessage to handle the case where it should start a new loop rather than respond to an existing ask

Testing Plan

• Write unit tests for the edit message flow with pending tool approval
• Test the scenario manually: start a task, trigger tool approval, edit a previous message
• Verify the edited message is properly sent and the UI does not hang

---

@roomote Please review this proposed plan and let me know if you approve this approach or have any feedback.

[wangqiang2512-lab]

Update on the root cause:

I found a critical detail for reproducing this bug: it only occurs when the assistant is specifically in the "Pending Tool Approval" state (i.e., when the Approve/Reject buttons are visible).

Trigger: Edit and resend a message while the buttons are waiting for user input.
Non-Trigger: If the tool has already been approved and the assistant has moved on to further processing (even if it's still running an API request), editing a previous message works correctly and does not cause message loss.
This suggests the issue is a state-handling conflict between the "Pending Approval" status and the chat history rewrite logic.