feat: Phase 5 - Background Tasks Panel UI

[roomote-v0]

This PR attempts to address Issue #12330 (Phase 5: Background Tasks Panel UI).

Summary

Builds on top of the Phase 4 BackgroundTaskRunner (PR #12342) to add user-visible UI for background tasks. This closes the visibility gap where background tasks were previously completely webview-silent.

Phase 5 MVP Scope

Included:

• Background Tasks Panel (collapsible section in the chat sidebar)
• Cancel button for running background tasks
• Badge showing count of active background tasks
• Basic result summary when a task completes
• State exposure via postStateToWebview

Deferred to Phase 6+:

• Full conversation replay for background tasks
• Real-time progress streaming of individual tool calls
• Tab switching between foreground/background task conversations
• Write-capable background tasks and file locking
• Persistent background task history across sessions

Key Changes

Types (packages/types)

• BackgroundTaskStatusInfo interface for exposing task status to webview
• backgroundTasks field on ExtensionState
• cancelBackgroundTask message type on WebviewMessage

BackgroundTaskRunner (src/core/task/BackgroundTaskRunner.ts)

• Tracks completed tasks in a ring buffer (max 10 recent)
• getTasksStatus() returns combined active + completed tasks for the UI
• onStateChanged callback for notifying the webview when tasks change
• Completed tasks record status (completed/cancelled/timed_out/error) with result summaries

ClineProvider (src/core/webview/ClineProvider.ts)

• postBackgroundTasksToWebview() for lightweight status-only updates
• backgroundTasks included in getStateToPostToWebview()
• handleBackgroundTaskComplete() passes result summary to the runner
• onStateChanged callback wired to refresh the webview

WebviewMessageHandler

• cancelBackgroundTask handler delegates to backgroundTaskRunner.cancelTask()

BackgroundTasksPanel (webview-ui/src/components/chat/BackgroundTasksPanel.tsx)

• Collapsible panel showing active and recently completed background tasks
• Each task shows: short ID, elapsed time, status icon with color
• Running tasks have a cancel button
• Completed tasks have a "Result" toggle to show the final summary
• Active count badge on the panel header
• Auto-hides when there are no background tasks

Testing

• 31 BackgroundTaskRunner tests (14 new covering getTasksStatus, completed buffer, onStateChanged, timeout tracking)
• 7 BackgroundTasksPanel UI tests (rendering, cancel, result toggle, collapse)
• All existing tests pass, all lint and type checks pass

Feedback and guidance are welcome!

Interactively review PR in Roo Code Cloud

[easonLiangWorldedtech]

@roomote Thanks for the clear PR description and the well-structured MVP scope.

I agree with keeping Phase 5 strictly within the boundaries you listed:

• Collapsible panel in the chat sidebar
• Cancel button + active count badge
• Basic result summary
• Lightweight state exposure via postBackgroundTasksToWebview

The clear separation between “Included” and “Deferred to Phase 6+” is very helpful for scope control. Let’s stick to this MVP for now.

A few points I’d like to align on before proceeding with review:

1. Result Summary content & granularity
   What exactly will be shown in the “basic result summary”?

   • Only the final AttemptCompletion message?
   • Or will it also include key tool outputs / short summaries?
     This decision will directly affect how we design context handoff in Phase 6. I suggest we keep it minimal for Phase 5 (final output + status only) to avoid carrying unnecessary state.

2. Panel placement & space usage
   Putting the collapsible panel in the chat sidebar with auto-hide looks reasonable. However, when 2–3 background tasks are running at the same time, could it start competing for vertical space with the main chat area? Any plans to make it more compact or allow repositioning later?

3. Cancel behavior
   Should we add a confirmation step before cancelling a background task? Also, after cancellation, is the current VS Code notification enough, or do we want to show clearer feedback inside the panel itself?

4. Phase 6 evolution path
   How much effort would it take to evolve this panel later into tabs or a separate Background Tasks view? Are there any extension points we should consider now to make future changes easier?

If we can first confirm the scope and content of the result summary, the rest should be straightforward. Would you be able to share a quick screenshot or example of what the result summary currently displays in the preview? That would help me understand the current implementation.

I’ll also review Phase 4 (#12342) shortly. It probably makes sense to get Phase 4 merged first before we finalize Phase 5, to keep the dependency clean.

Thanks for the work on this!

[roomote-v0]

Fixaroo   See task

Addressed the review feedback: added two-click cancel confirmation, panel max-height scroll constraint (200px) to prevent vertical space competition, and Phase 6 extension-point comments in both BackgroundTaskRunner and BackgroundTasksPanel. All 31 backend + 7 UI tests pass, lint and type checks clean.

_{View commit | Revert commit}

[easonLiangWorldedtech]

@roomote-v0[bot] Thanks for the quick updates.

The changes look good:

• Two-click cancel confirmation improves safety
• 200px max-height + scroll constraint effectively prevents UI space competition
• Adding Phase 6 extension-point comments in both BackgroundTaskRunner and BackgroundTasksPanel is helpful for future evolution

All tests still pass and the scope remains clean.

A couple of small follow-ups:

1. Could you share the exact comments you added for the Phase 6 extension points? I want to make sure the direction aligns with what we discussed for context handoff.
2. With the 200px constraint, is the panel still easy to use when there are 3+ active tasks? (Just want to confirm the UX feels acceptable)

Once these are confirmed, I’m comfortable moving forward. I’ll also review Phase 4 shortly so we can keep the dependency order clean.

Thanks again!

[roomote-v0]

Proofessor   See task

Here are the answers to both questions:

---

1. Phase 6 Extension-Point Comments

Two blocks were added:

src/core/task/BackgroundTaskRunner.ts (file header, lines 12-20):

Phase 6+ extension points:
- To support write-capable background tasks, extend BACKGROUND_TASK_ALLOWED_TOOLS
  and add a file-locking mechanism to prevent conflicts with foreground edits.
- For real-time progress streaming, add an `onProgressUpdate` callback to
  BackgroundTaskInfo and emit partial tool-call summaries from Task.
- For persistent history across sessions, serialize completedTasks to global
  state via the TaskHistoryStore and restore on provider initialization.
- For tab-based switching, expose the background task's clineMessages via
  getTasksStatus() so the webview can render a full conversation view.

webview-ui/src/components/chat/BackgroundTasksPanel.tsx (component JSDoc, lines 144-152):

Phase 6+ evolution notes:
- This panel can be promoted to a tab-based view alongside the main chat
  by extracting the task list into a shared component and rendering it in
  both the sidebar panel and a dedicated "Background Tasks" tab.
- For real-time progress streaming, each BackgroundTaskItem could accept
  a `progressMessages` prop with the last N tool-call summaries.
- For conversation replay, clicking a completed task could open its full
  message history in a read-only chat view (reuse ChatView with a
  `readOnly` flag and the task's clineMessages).

The backend comments focus on the data/infrastructure side (tool allowlist, callbacks, serialization, message exposure), while the frontend comments describe how the UI would evolve to consume those capabilities. Together they sketch a clean handoff path for context: the runner exposes clineMessages via getTasksStatus(), and the panel renders them through a readOnly ChatView or progressMessages prop.

---

2. UX with 200px Constraint and 3+ Active Tasks

The panel is usable with 3+ tasks. Here's the breakdown:

• Each BackgroundTaskItem uses px-2 py-1.5 padding with border and mb-1 margin, which comes to roughly 34-38px per row (depending on font size).
• At 200px of scrollable area (max-h-[200px] overflow-y-auto), that fits 5 task rows comfortably without scrolling.
• For 6+ tasks, the scroll kicks in smoothly -- the items are compact enough that scrolling feels natural.
• The result summary expansion (max-h-24 = 96px) is independently scrollable inside each item, so expanding a result doesn't push all other items out of view.
• The panel header (with badge count and total) stays fixed outside the scroll container, so context is never lost.

In short: 3 tasks display fully without scrolling, 5 tasks still fit, and beyond that the scroll behavior handles it cleanly. The UX is acceptable.

[easonLiangWorldedtech]

@roomote-v0[bot] Thanks for the detailed answers to both questions. This is helpful.

The Phase 6 extension-point comments you added are clear and well-aligned with the overall direction of parallel execution and context handoff. The backend and frontend notes together form a reasonable evolution path.

The UX explanation for the 200px max-height constraint is also acceptable — 5 tasks fitting comfortably with smooth scrolling beyond that works for the MVP.

At this point the implementation looks good and stays within the defined Phase 5 MVP scope.

Please mark this PR as ready for review and request reviews from the code owners.

Thanks for keeping the progress moving cleanly.

[roomote-v0]

Fixaroo   See task

Done. PR has been marked as ready for review and reviews have been requested from all code owners (@mrubens, @cte, @jr, @hannesrudolph, @daniel-lxs).

[roomote-v0]

Closing as part of PR restructuring per issue #12330. This work will be combined into the new Remaining Phases (4+5+6) PR with proper stacked branching.