[BUG] Orchestrator: subtask completion button disappears; resuming re-executes and incurs extra token costs

[rcdailey]

Type

Bug

Problem / Value

After completing a subtask in Orchestrator mode, the completion button disappears. Resuming the subtask triggers the task to re-execute, causing duplicate work and extra model token costs.

Context

• App: 3.21.1
• Provider: OpenRouter
• Model: Claude Sonnet 4
• Flow: Orchestrator mode with a subtask that finished; user navigated back, then returned to subtask.

Reproduction

1 Start Orchestrator mode and run a subtask to completion (button shown: “Complete subtask and return to parent task”)
2) Navigate back to the task list
3) Return to the subtask chat
4) Observe the completion button is gone; only “Cancel” and “Resume Task” appear
5) Click “Resume Task”
6) The system re-executes the completed subtask, incurring additional costs
7) Returning to the parent task triggers re-analysis of the same files

Expected

• The completed subtask remains in a completed state with a clear action to return to the parent task
• Resuming does not re-run already completed work or incur additional token costs

Actual

• Completion control disappears; “Resume Task” re-runs the completed work and charges tokens again

Acceptance Criteria

• Completed subtasks retain a visible, reliable control to return to the parent task
• Resuming a completed subtask does not re-execute work or consume additional tokens
• Parent task recognizes completed subtask outputs and does not re-analyze the same artifacts
• Clear, consistent UI state across navigation (task list → subtask → parent)

Notes

• If logs are needed, provide a path/instruction so users can capture them during reproduction
  EOF
  )

[dosubot]

Hi @rcdailey! I'm Dosu and I’m helping the Roo-Code team.

I couldn't find any documentation or release notes specifically mentioning disappearing subtask completion buttons or duplicate token costs in orchestrator mode for version 3.21.1. However, the docs clarify that orchestrator mode requires explicit approval to complete subtasks, and the UI should offer a "Complete subtask and return to parent task" button when a subtask finishes. If you leave and return to a subtask, the system may not recognize it as ready for completion, which could explain why the button disappears and "Resume Task" triggers a re-execution instead of returning to the parent task. This behavior is likely due to how Roo Code manages task state and context isolation between subtasks and parent tasks, requiring explicit signaling to properly return to the parent task and avoid unnecessary re-execution and token costs (source, source).

I couldn't find guidance on capturing logs for orchestrator mode. If you want to try reproducing the issue and capturing logs, let me know what OS/editor you're using and I can help look for log file locations or debug options.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[daniel-lxs]

After reviewing PR #4883 and analyzing the codebase, I've identified that the root cause is the loss of subtask UI context when navigating away and returning to a subtask.

The core problem is that when a subtask is active, it correctly shows the "Complete subtask and return to parent task" button. But this UI state isn't preserved when you navigate to the task list and come back. Instead, you get the generic "Cancel" and "Resume Task" buttons.

PR #4883 tries to detect completed subtasks by looking for finishTask tool calls, but this only handles completed subtasks, not in-progress ones. It's addressing a symptom rather than the root cause.

A better solution would focus on preserving subtask context during task resumption. When resuming any task that has a parentTask, it should maintain the subtask UI state. Instead of only showing the "Complete subtask and return to parent task" button during the completion flow, it should also appear when resuming a subtask that hasn't been explicitly finished yet.

One approach could be adding a new ask type like "resume_subtask" that would trigger the appropriate UI:

// In Task.ts resumeTask method
let askType: ClineAsk
if (lastClineMessage?.ask === "completion_result") {
    askType = "resume_completed_task"
} else if (this.parentTask) {
    // This is a subtask that needs special UI handling
    askType = "resume_subtask" // New ask type
} else {
    askType = "resume_task"
}

Then the webview could handle this new ask type to show the subtask-specific buttons. This would ensure any subtask maintains its proper UI context when reopened, whether it's completed or still in progress.