Push Notification Implementation Plan
This document outlines the comprehensive plan for improving VibeTunnel’s notification system through two major initiatives:- Creating a dedicated Notifications tab in macOS settings
- Migrating SessionMonitor from the Mac app to the server for unified notifications
Overview
Currently, VibeTunnel has inconsistent notification implementations between the Mac and web clients. The Mac app has its own SessionMonitor while the web relies on server events. This leads to:- Different notification behaviors between platforms
- Missing features (e.g., Claude Turn notifications not shown in web UI)
- Duplicate code and maintenance burden
- Inconsistent descriptions and thresholds
Part 1: macOS Settings Redesign
Current State
- Notification settings are cramped in the General tab
- No room for descriptive text explaining each notification type
- Settings are already at 710px height (quite tall)
- Missing helpful context that exists in the web UI
Proposed Solution: Dedicated Notifications Tab
1. Add Notifications Tab to SettingsTab enum
2. Create NotificationSettingsView.swift
3. Create Reusable NotificationToggleRow Component
4. Update SettingsView.swift
5. Update GeneralSettingsView.swift
Remove all notification-related settings to free up space.Standardized Notification Descriptions
Use these descriptions consistently across Mac and web:Type | Title | Description |
---|---|---|
Session Start | Session starts | When a new session starts (useful for shared terminals) |
Session Exit | Session ends | When a session terminates or crashes (shows exit code) |
Command Error | Commands fail | When commands fail with non-zero exit codes |
Command Completion | Commands complete (> 3 seconds) | When commands taking >3 seconds finish (builds, tests, etc.) |
Terminal Bell | Terminal bell (🔔) | Terminal bell (^G) from vim, IRC mentions, completion sounds |
Claude Turn | Claude turn notifications | When Claude AI finishes responding and awaits input |
Part 2: Server-Side SessionMonitor Migration
Current Architecture
Proposed Architecture
Implementation Steps
1. Create Server-Side SessionMonitor
2. Enhance Event Types
3. Integrate with PtyManager
4. Update Server Routes
5. Update Mac NotificationService
6. Update Web Notification Service
7. Add Claude Turn to Web UI
Migration Strategy
Phase 1: Preparation (Non-breaking)
- Implement server-side SessionMonitor alongside existing system
- Add new event types to shared types
- Update web UI to show Claude Turn option
Phase 2: Server Enhancement (Non-breaking)
- Deploy enhanced server with SessionMonitor
- Server emits both old and new event formats
- Test with web client to ensure compatibility
Phase 3: Mac App Migration
- Update Mac app to consume server events
- Keep fallback to local monitoring if server unavailable
- Remove local SessionMonitor once stable
Phase 4: Cleanup
- Remove old event formats from server
- Remove local SessionMonitor code from Mac
- Document new architecture
Testing Plan
Unit Tests
- SessionMonitor Claude detection logic
- Event threshold calculations
- Activity state transitions
Integration Tests
- Server events reach both Mac and web clients
- Notification preferences are respected
- Claude Turn notifications work correctly
- Bell character detection
Manual Testing
- Test each notification type on both platforms
- Verify descriptions match
- Test with multiple clients connected
- Test offline Mac app behavior
Success Metrics
- Consistency: Same notifications appear on Mac and web for same events
- Feature Parity: Claude Turn available on both platforms
- Performance: No noticeable lag in notifications
- Reliability: No missed notifications
- Maintainability: Single codebase for monitoring logic
Timeline Estimate
- Week 1: Implement macOS Notifications tab
- Week 2: Create server-side SessionMonitor
- Week 3: Integrate and test with web client
- Week 4: Migrate Mac app and testing
- Week 5: Polish, documentation, and deployment
Risks and Mitigations
Risk | Impact | Mitigation |
---|---|---|
Breaking existing notifications | High | Phased rollout, maintain backwards compatibility |
Performance impact on server | Medium | Efficient event handling, consider debouncing |
Mac app offline mode | Medium | Keep local fallback for critical notifications |
Complex migration | Medium | Detailed testing plan, feature flags |
Conclusion
This two-part implementation will:- Provide a better UI for notification settings on macOS
- Create a unified notification system across all platforms
- Reduce code duplication and maintenance burden
- Ensure consistent behavior for all users