Notification for Actions

[Basilakis]

What specific problem does this solve?

Roo Code Notification Service Requirements

1. Overview

The Roo Code notification service is designed to alert users when the AI agent has pending messages or requires user interaction. This cross-platform notification system will integrate with the existing Roo Code architecture to provide timely, contextual notifications across Windows, Linux, and macOS.

2. Core Requirements

2.1 Functional Requirements

2.1.1 Notification Triggers

• Agent Approval Requests: Notify when agent requests approval for actions (e.g., browser launches, file operations)
• Error Conditions: Alert when agent encounters errors requiring user intervention
• Task Completion: Notify when agent completes requested tasks
• User Input Required: Alert when agent is waiting for user response or clarification
• Session Timeouts: Warn when agent session is about to expire due to inactivity

2.1.2 Notification Content

• Title: Clear, concise description of the notification type
• Message Body: Contextual information about what action is required
• Priority Level: Critical, High, Medium, Low priority indicators
• Action Buttons: Quick action options (Approve, Deny, View Details, Dismiss)
• Timestamp: When the notification was generated

2.1.3 Cross-Platform Support

• Windows: Native Windows notification system integration
• macOS: Native macOS notification center integration
• Linux: Desktop environment notification support (GNOME, KDE, etc.)

2.2 Non-Functional Requirements

2.2.1 Performance

• Notification delivery within 500ms of trigger event
• Minimal system resource usage (<10MB RAM)
• No impact on agent performance

2.2.2 Reliability

• 99.9% notification delivery success rate
• Graceful degradation when notification system unavailable
• Retry mechanism for failed notifications

2.2.3 User Experience

• Non-intrusive notification display
• Customizable notification preferences
• Support for Do Not Disturb modes

3. Technical Requirements

3.1 Integration Points

3.1.1 Agent Integration

interface NotificationTrigger {
  type: 'approval_request' | 'error' | 'completion' | 'input_required' | 'timeout_warning'
  priority: 'critical' | 'high' | 'medium' | 'low'
  title: string
  message: string
  context?: {
    toolName?: string
    action?: string
    errorType?: string
    sessionId: string
  }
  actions?: NotificationAction[]
}

interface NotificationAction {
  id: string
  label: string
  action: 'approve' | 'deny' | 'view' | 'dismiss' | 'custom'
}

3.1.2 Service Interface

interface NotificationService {
  initialize(): Promise<void>
  sendNotification(notification: NotificationTrigger): Promise<boolean>
  updateNotification(id: string, updates: Partial<NotificationTrigger>): Promise<boolean>
  dismissNotification(id: string): Promise<boolean>
  setUserPreferences(preferences: NotificationPreferences): Promise<void>
  isSupported(): boolean
}

3.2 Platform-Specific Implementation

3.2.1 Windows

• Use Windows 10/11 Toast Notifications API
• Support for action buttons and custom sounds
• Integration with Windows notification settings

3.2.2 macOS

• Use macOS User Notifications framework
• Support for banner and alert styles
• Integration with macOS notification preferences

3.2.3 Linux

• Use desktop notification specification (freedesktop.org)
• Support for major desktop environments
• Fallback to system tray notifications

3.3 Configuration Management

3.3.1 User Preferences

interface NotificationPreferences {
  enabled: boolean
  priority: {
    critical: boolean
    high: boolean
    medium: boolean
    low: boolean
  }
  quietHours: {
    enabled: boolean
    startTime: string // HH:MM format
    endTime: string   // HH:MM format
  }
  sound: {
    enabled: boolean
    customSoundPath?: string
  }
  position: 'top-right' | 'top-left' | 'bottom-right' | 'bottom-left'
  duration: number // seconds, 0 for persistent
}

4. Implementation Architecture

4.1 Service Components

4.1.1 Notification Manager

• Central coordination of all notifications
• Queue management for multiple notifications
• Deduplication of similar notifications

4.1.2 Platform Adapters

• Windows notification adapter
• macOS notification adapter
• Linux notification adapter

4.1.3 Configuration Store

• User preference persistence
• Platform-specific settings management

4.2 Integration with Existing Code

Based on the provided browser action tool, integration points would include:

// In browserActionTool function
export async function browserActionTool(
    cline: Task,
    // ... existing parameters
    notificationService: NotificationService
) {
    // ... existing code

    if (action === "launch") {
        // Send notification for approval request
        const approvalNotification: NotificationTrigger = {
            type: 'approval_request',
            priority: 'high',
            title: 'Browser Launch Approval Required',
            message: `Agent requests permission to launch browser and navigate to: ${url}`,
            context: {
                toolName: 'browser_action',
                action: 'launch',
                sessionId: cline.sessionId
            },
            actions: [
                { id: 'approve', label: 'Approve', action: 'approve' },
                { id: 'deny', label: 'Deny', action: 'deny' }
            ]
        }
        
        await notificationService.sendNotification(approvalNotification)
        
        const didApprove = await askApproval("browser_action_launch", url)
        // ... rest of existing code
    }

    // Error handling with notifications
    catch (error) {
        const errorNotification: NotificationTrigger = {
            type: 'error',
            priority: 'critical',
            title: 'Browser Action Error',
            message: `Failed to execute browser action: ${action}`,
            context: {
                toolName: 'browser_action',
                action: action,
                errorType: error.name,
                sessionId: cline.sessionId
            }
        }
        
        await notificationService.sendNotification(errorNotification)
        // ... existing error handling
    }
}

5. Security Considerations

5.1 Data Protection

• No sensitive data in notification content
• Secure storage of user preferences
• Encryption of notification payloads if transmitted

5.2 Permission Management

• Request appropriate system permissions
• Graceful handling of permission denials
• User control over notification access

Additional context (optional)

No response

Request checklist

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

Interested in implementing this?

• Yes, I'd like to help implement this feature

Implementation requirements

• I understand this needs approval before implementation begins

How should this be solved? (REQUIRED if contributing, optional otherwise)

No response

How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)

No response

Technical considerations (REQUIRED if contributing, optional otherwise)

No response

Trade-offs and risks (REQUIRED if contributing, optional otherwise)

No response

[daniel-lxs]

I took a closer look at this and wanted to share a quick technical breakdown.

Right now, Roo Code uses VSCode’s built-in messaging functions like showInformationMessage(), showWarningMessage(), and showErrorMessage(), which only display inside the editor. These notifications don’t show up when VSCode is minimized or running in the background.

The main limitation is that the VSCode Extension API doesn’t support true OS-level system notifications. This seems to be an intentional restriction for security and consistency.

One possible workaround might be to use something like node-notifier, which can trigger native notifications outside of the editor. That said, I’m not sure if it’s a good idea. It introduces platform-specific behavior, additional dependencies, and might complicate the extension’s architecture. It also wouldn’t integrate cleanly with our existing notification settings, and fallback behavior could be inconsistent across systems.

It’s technically feasible using native modules or a separate helper process, but it’s a non-trivial change. We’d need to handle cross-platform support, permission management, and proper testing on different OSes.

Open to thoughts if others have a cleaner approach in mind.

[Basilakis]

@daniel-lxs https://github.com/search?q=repo%3AKilo-Org%2Fkilocode%20command%20notification&type=code

this is already happening here, please do take a look. My request is coming from there and I have analyzed it

[daniel-lxs]

@Basilakis Thank you for sharing that, I like their implementation.

I'll reopen this issue and mark it as actionable.