[ENHANCEMENT] Ability to select specific terminal instance when using @terminal to prevent context pollution

[Rayano79]

Problem (one or two sentences)

Currently, using @Terminal attaches the output from all active terminal instances indiscriminately. This floods the LLM context with irrelevant logs (e.g., from background processes or installation tabs), wasting tokens and degrading model performance.

Context (who is affected and when)

This affects users working with multiple terminal tabs (e.g., one for server logs, another for git commands, and a third for package installation). When a user needs the LLM to analyze an error in just one specific tab, they are currently forced to close all other tabs to isolate the context, which disrupts the workflow.

Desired behavior (conceptual, not technical)

When invoking @Terminal, the interface should allow the user to select a specific open terminal instance by its name. The context sent to the LLM should be strictly limited to the logs/output of that selected instance, rather than merging all open terminals.

Constraints / preferences (optional)

It would be ideal to keep the UI selection quick, perhaps appearing as a sub-list when typing @Terminal, or allowing a syntax like @Terminal:name.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

1.User can distinguish between multiple open terminal instances in the context picker.

2.Selecting a specific terminal sends only that instance's buffer to the LLM.

3.Token usage is reduced by excluding irrelevant terminal outputs.

Proposed approach (optional)

Modify the @Terminal context provider to enumerate active VS Code terminal instances. Instead of a single action that grabs all buffers, present a list of instances (using window.terminals API) for the user to pick from.

Trade-offs / risks (optional)

This adds a slight UI layer to the selection process. To mitigate friction for users who do want everything, an "All Terminals" option could be retained as a choice.

[roomote]

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

Overview

The enhancement involves allowing users to select a specific terminal instance when using @terminal, rather than grabbing output from the currently active terminal.

Proposed Changes

1. Add Terminal Selection Context Menu Type

In webview-ui/src/utils/context-mentions.ts:

• Add a new sub-selection pattern for Terminal (similar to how Git currently works)
• When user types @terminal, show available terminal instances as sub-options

2. Extension Backend Changes

In src/core/mentions/index.ts:

• Modify parseMentions() to handle @terminal:name syntax where "name" identifies a specific terminal
• Add logic to retrieve output from a specific terminal by name/index

In src/integrations/terminal/TerminalRegistry.ts:

• Add method to get terminal by name: getTerminalByName(name: string)
• Add method to list all available user terminals: getAllUserTerminals()

3. Webview Communication

Add new message types for terminal list communication:

• requestTerminals - webview asks extension for list of available terminals
• terminalListResults - extension returns array of {name: string, id: number} objects

4. Context Menu UI Updates

In webview-ui/src/components/chat/ChatTextArea.tsx:

• Similar to Git commits handling, fetch terminal list when @terminal is typed
• Display terminals as selectable sub-options with their names
• Include an "All Terminals" option to retain current behavior

In webview-ui/src/components/chat/ContextMenu.tsx:

• Add rendering for terminal instance options

5. Terminal Output Retrieval

Create a new method to get output from a specific terminal instance using VS Code's terminal API (window.terminals), selecting the appropriate terminal before retrieving its output.

Benefits

• Users can precisely select which terminal output to include in context
• Reduces token waste from irrelevant terminal logs
• Maintains backward compatibility with "All Terminals" option
• Follows existing patterns (similar to Git selection)

Trade-offs

• Adds slight UI complexity (one extra selection step)
• Requires maintaining terminal name-to-instance mapping

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

[Rayano79]

@roomote I approve this plan. It perfectly addresses the issue described. Please proceed.

[roomote]

Thanks for the approval! I'm starting the implementation now. I'll create a draft PR shortly with the terminal selection feature following the approved plan.

[roomote]

Opened a draft PR with my attempt at implementing this feature: #10634

The implementation follows the approved plan:

• Added terminal sub-selection menu when selecting @terminal
• Supports @terminal:name syntax to reference specific terminals
• Includes "All Terminals" option to preserve existing behavior

Feedback welcome!