Add 'Add & Run' button to command approval UI for streamlined whitelisting

[hannesrudolph]

What specific problem does this solve?

When using Roo Code with auto-approve mode enabled, users encounter a command approval dialog when a command is not whitelisted. Currently, this dialog only offers two options:

• "Run Command" - Executes the command once
• "Reject" - Cancels the command

Who is affected: All users who use terminal commands with auto-approve mode enabled
When this happens: Every time a non-whitelisted command needs to be executed
Current behavior: Users must manually go to settings to whitelist frequently used commands after approving them
Expected behavior: Users should be able to whitelist and run a command in one action
Impact: Time wasted switching between command approval and settings, interrupting workflow for repetitive command approvals

Additional context

Other tools in the ecosystem (like similar AI coding assistants) offer a third option that allows users to both add the command to the whitelist and execute it immediately. This saves time and reduces friction when working with trusted commands.

---

🛠️ Contributing & Technical Analysis

✅ I'm interested in implementing this feature
✅ I understand this needs approval before implementation begins

How should this be solved?

Add a third button "Add & Run" to the command approval UI with a two-row layout:

What will change:

• Modify the approval UI to support three buttons instead of two
• Implement a two-row button layout:
  • Top row: "Run" and "Add & Run" buttons
  • Bottom row: "Reject" button
• Add tooltips to each button for clarity:
  • "Run": "Execute this command once"
  • "Add & Run": Dynamic tooltip showing what pattern will be whitelisted (e.g., "Add 'gh pr checkout' to whitelist and execute")
  • "Reject": "Cancel command execution"
• Implement intelligent command pattern extraction using shell-quote v1.8.3

User interaction:

• When a non-whitelisted command is triggered, users see the three-button dialog
• Hovering over "Add & Run" shows exactly what command pattern will be whitelisted
• Clicking "Add & Run" will:
  1. Extract the command pattern (e.g., "gh pr checkout" from "gh pr checkout 1234")
  2. Add the pattern to the whitelist in settings
  3. The command automatically proceeds (existing behavior when added to whitelist)
  4. Future executions of commands matching this pattern will be auto-approved

Acceptance Criteria

Given a non-whitelisted command is about to be executed
When the command approval dialog appears
Then three buttons are displayed in a two-row layout
And the top row contains "Run" and "Add & Run" buttons
And the bottom row contains the "Reject" button
And each button has an appropriate tooltip
And hovering over "Add & Run" shows the exact pattern that will be whitelisted

Given the user hovers over the "Add & Run" button for command "gh pr checkout 1234"
When the tooltip appears
Then it displays "Add 'gh pr checkout' to whitelist and execute"
And the pattern shown excludes the dynamic argument "1234"

Given the user clicks "Add & Run"
When the action is processed
Then the extracted command pattern is added to the allowedCommands whitelist
And the command automatically proceeds (existing whitelist behavior)
And future executions of commands matching this pattern are auto-approved
But the dialog does not appear again for commands matching this pattern

Technical Considerations

Implementation approach:

• Key files to modify:
  • src/core/tools/executeCommandTool.ts - Extend askApproval to handle third option
  • webview-ui/src/components/chat/ChatView.tsx - Add third button UI support
  • src/core/assistant-message/presentAssistantMessage.ts - Update askApproval function
  • src/shared/extract-command-pattern.ts - NEW FILE: Implement pattern extraction logic
  • webview-ui/src/utils/command-validation.ts - Import and use extractCommandPattern
  • Message passing between extension and webview for the new action

Pattern extraction implementation:

// src/shared/extract-command-pattern.ts
import { parse } from 'shell-quote';

function extractCommandPattern(command: string): string {
  const tokens = parse(command).filter(t => typeof t === 'string') as string[];
  
  const staticTokens: string[] = [];
  for (const token of tokens) {
    // Stop on tokens that look like variables (starts with -, number, $, ", ', /)
    if (/^[\-0-9$"'`\/]/.test(token)) break;
    staticTokens.push(token);
  }
  
  return staticTokens.join(' ');
}

// Examples:
// extractCommandPattern('gh pr checkout 1234') → 'gh pr checkout'
// extractCommandPattern('echo "hello world"') → 'echo'
// extractCommandPattern('npm install lodash') → 'npm install'

Current architecture:

• The approval system currently only supports primary/secondary buttons
• Need to extend the message protocol to support a third action
• Command validation uses prefix matching in validateCommand
• Important: Adding to whitelist already triggers command execution automatically
• Must install shell-quote@1.8.3 as a dependency

Integration points:

• Leverage existing handleAddCommand function from AutoApproveSettings
• Ensure proper state synchronization between approval UI and settings
• No need for separate execution logic - whitelist addition handles this
• Tooltip must dynamically show the extracted pattern before user clicks

Performance implications:

• Minimal - only adds one additional button and reuses existing whitelist logic
• Pattern extraction is fast and happens on hover/click

Compatibility concerns:

• Need to ensure backward compatibility with existing approval flows
• Consider how this interacts with other auto-approve settings

Trade-offs and Risks

Alternatives considered:

• Single "Add & Run" button replacing "Run": Would force whitelisting for one-time commands
• Dropdown menu approach: More complex UI, slower user interaction
• Keep two buttons with modifier key: Less discoverable for users
• Full command whitelisting: Would whitelist "gh pr checkout 1234" instead of "gh pr checkout", limiting reusability

Potential risks:

• Users might accidentally whitelist dangerous command patterns: Mitigation - clear tooltips showing exact pattern and button positioning
• Pattern extraction might be too aggressive: Mitigation - conservative heuristic that stops at first argument-like token
• Three buttons might clutter the UI: Mitigation - two-row layout keeps it organized
• Increased complexity in approval flow: Mitigation - reuse existing whitelist logic

Breaking changes:

• None expected - this is an additive change to the UI