WebKit.WebContent High CPU Usage (60-75%) Causing Severe UI Lag on v0.7.48

[damianpdr]

Bug Report: WebKit.WebContent High CPU Usage Causing UI Lag

Description

CodexMonitor's WebKit.WebContent process consistently consumes 60-75% CPU and 1-1.7GB RAM, causing severe UI lag (500ms-2s delay on clicks) even on an M2 MacBook Pro with 16GB RAM.

Environment

• CodexMonitor Version: 0.7.48
• macOS: 15.6.1 (24G90)
• Hardware: MacBook Pro M2 (Apple Silicon)
• RAM: 16GB
• Installation Method: DMG download from GitHub releases

Steps to Reproduce

1. Launch CodexMonitor v0.7.48
2. Wait 30-60 seconds for app to fully initialize
3. Interact with UI (click sidebar items, switch threads)
4. Observe significant lag on every interaction

Expected Behavior

UI should be responsive with <100ms click latency, WebKit process should idle at <5% CPU.

Actual Behavior

• WebKit.WebContent process: 60-75% CPU, 1-1.7GB RAM
• CodexMonitor main process: normal (~0-5% CPU, ~100-150MB RAM)
• UI lag: 500ms-2s delay on every click
• System load average spikes to 10-40

Process Details

PID 17784: WebKit.WebContent
- CPU: 66.2% → 75.3% (spikes)
- RAM: 1.0GB → 1.7GB (grows over time)
- Parent: launchd (system process)

Diagnostic Data

Memory Pressure:

• System-wide free: 45-47% (was lower during peak usage)
• Swap I/O active: 120,000+ swapouts observed
• Compressed pages: 6M+ pages

Top Memory Consumers During Issue:

1. WebKit.WebContent (CodexMonitor): ~1.7GB RAM, 75% CPU
2. Google Chrome: ~2.9GB RAM (multiple processes)
3. Antigravity (VS Code): ~1.6GB RAM
4. Wispr Flow: ~0.6GB RAM

System State:

Load Avg: 3.56 - 40.24
PhysMem: 15G used (94% utilization)
Free RAM: ~74MB (critically low)

Attempted Workarounds

1. ✅ Killed WebKit process manually - Immediate relief, but WebKit respawns and problem returns
2. ✅ Restarted CodexMonitor - Process resets to ~150MB/0% CPU, then grows back to 1GB+/60%+ CPU within minutes
3. ✅ Reduced workspaces - Removed several workspaces, minimal impact
4. ❌ System restart - Not attempted yet
5. ❌ Reset CodexMonitor settings - Not attempted yet (risk of losing workspace config)

Root Cause Analysis

The issue appears to be application-level, not system-level:

• WebKit process consistently enters "spin loop" state after app startup
• Problem persists across app restarts (fresh WebKit process exhibits same behavior)
• Other Tauri/WebKit apps on same system do not show this behavior
• CPU profile shows WebKit in IPC::Connection::dispatchIncomingMessages() loops

Hypothesis

Possible causes:

1. React rendering loop - UI component stuck in infinite re-render cycle
2. Thread status polling - Excessive polling of codex app-server processes
3. WebSocket/IPC message flooding - Rapid message exchange between main process and WebKit
4. Large workspace/thread list - Rendering performance issue with many items

Logs

WebKit process suspension logs show rapid foreground/background activity cycling:

ProcessThrottler::Activity::Activity: Starting foreground activity
ProcessThrottler::Activity::invalidate: Ending foreground activity
WebProcessProxy::didChangeThrottleState: type=1

Impact

• Severity: High - App becomes unusable for productive work
• Frequency: Always reproducible after app startup
• Workaround: None effective (only temporary relief via process kill)

Request

Please investigate:

1. Memory leak in React/Tauri frontend
2. IPC message handling efficiency
3. Thread/workspace polling frequency
4. Any recent changes in v0.7.48 that might affect WebKit performance

Happy to provide additional diagnostics (sample traces, memory graphs, etc.) upon request.

[damianpdr]

Additional Testing:

I also tested version 0.7.47 and the same issue occurs - WebKit.WebContent process consistently hits 60-75% CPU and 1GB+ RAM usage with severe UI lag.

This indicates the bug is not specific to v0.7.48 and likely exists in earlier versions as well. The issue appears to be a deeper performance problem with the WebKit/WebView implementation rather than a recent regression.

Happy to test earlier versions (0.7.46, 0.7.45, etc.) if helpful for bisecting when this was introduced.

[damianpdr]

Detailed Bug Analysis: WebKit High CPU Usage in CodexMonitor v0.7.48

🔴 Root Cause Identified

The high CPU usage (60-75%) in WebKit.WebContent process is caused by a React useEffect dependency issue in useAppServerEvents.ts combined with aggressive polling in multiple hooks.

Primary Issue: useAppServerEvents Hook

File: src/features/app/hooks/useAppServerEvents.ts
Line: 451

export function useAppServerEvents(handlers: AppServerEventHandlers) {
  useEffect(() => {
    const unlisten = subscribeAppServerEvents((payload) => {
      // ... event handling logic
    });

    return () => {
      unlisten();
    };
  }, [handlers]);  // ❌ PROBLEM: handlers object recreated every render
}

Why this causes high CPU:

1. handlers is an object containing 20+ callback functions
2. Even if individual callbacks use useCallback, the handlers object itself is recreated on every render
3. This causes the useEffect to re-run on EVERY render
4. Each re-run calls subscribeAppServerEvents() which adds a new listener to the event hub
5. The cleanup function (unlisten()) runs, but there's a race condition window
6. Result: Multiple active listeners processing the same events → exponential CPU usage growth

Secondary Issues: Multiple Polling Mechanisms

1. useWorkspaceFiles.ts (Lines 117-127)

const REFRESH_INTERVAL_MS = 5000;  // Every 5 seconds!
const LARGE_REFRESH_INTERVAL_MS = 20000;  // 20 seconds for large workspaces

useEffect(() => {
  const interval = window.setInterval(() => {
    refreshFiles().catch(() => {});
  }, refreshInterval);
  // ...
}, [files.length, isConnected, isPollingEnabled, refreshFiles, workspaceId]);

2. useLocalUsage.ts (Line 17)

const REFRESH_INTERVAL_MS = 5 * 60 * 1000;  // Every 5 minutes

3. useWorkspaceRefreshOnFocus.ts

• Refreshes ALL workspaces on window focus
• Triggers thread list updates for ALL connected workspaces
• Can cause cascading updates

4. MessageRows.tsx (Lines 289-293)

const interval = window.setInterval(() => {
  setElapsedMs(Date.now() - processingStartedAt);
}, 1000);  // Updates every second while thinking

📊 Evidence from System Analysis

Memory Leak Pattern

• WebKit.WebContent: 1.0GB → 1.7GB over time
• CPU: 66% → 75% sustained
• Process count grows with app usage

Event Listener Explosion

The event hub uses a Set<Listener<T>> to store listeners:

const listeners = new Set<Listener<T>>();

If the useEffect re-runs 60 times per second (due to rapid state changes), and each listener processes IPC messages, CPU usage explodes.

🔧 Proposed Fixes

Fix 1: Stabilize useAppServerEvents Dependencies

Option A: Use individual callback dependencies

export function useAppServerEvents(handlers: AppServerEventHandlers) {
  const {
    onWorkspaceConnected,
    onThreadStarted,
    onAgentMessageDelta,
    // ... destructure all 20+ handlers
  } = handlers;

  useEffect(() => {
    const unlisten = subscribeAppServerEvents((payload) => {
      // handle events using local refs
    });
    return () => unlisten();
  }, [
    onWorkspaceConnected,
    onThreadStarted,
    onAgentMessageDelta,
    // ... individual stable callbacks
  ]);
}

Option B: Use a ref for handlers (Recommended)

export function useAppServerEvents(handlers: AppServerEventHandlers) {
  const handlersRef = useRef(handlers);
  
  // Keep ref current without triggering re-subscription
  useEffect(() => {
    handlersRef.current = handlers;
  });

  useEffect(() => {
    const unlisten = subscribeAppServerEvents((payload) => {
      // Access latest handlers via ref
      const currentHandlers = handlersRef.current;
      // ... handle events
    });
    return () => unlisten();
  }, []); // ✅ Empty deps - subscribe once
}

Fix 2: Reduce Polling Frequency

useWorkspaceFiles.ts:

// Current: 5 seconds
const REFRESH_INTERVAL_MS = 30000;  // 30 seconds
const LARGE_REFRESH_INTERVAL_MS = 60000;  // 60 seconds

Add visibility-based pausing:

useEffect(() => {
  if (!workspaceId || !isConnected || !isPollingEnabled) {
    return;
  }
  
  // Pause polling when tab is hidden
  if (document.visibilityState === 'hidden') {
    return;
  }
  
  const interval = window.setInterval(() => {
    refreshFiles().catch(() => {});
  }, refreshInterval);
  
  return () => window.clearInterval(interval);
}, [/* deps */]);

Fix 3: Debounce Rapid Updates

For MessageRows.tsx elapsed time:

// Instead of setInterval every 1 second
// Use requestAnimationFrame or longer interval (5 seconds)
const interval = window.setInterval(() => {
  setElapsedMs(Date.now() - processingStartedAt);
}, 5000);  // Update every 5 seconds is sufficient

Fix 4: Memoize Handler Objects

In the component using useAppServerEvents:

const handlers = useMemo(() => ({
  onWorkspaceConnected: handleWorkspaceConnected,
  onThreadStarted: handleThreadStarted,
  // ... all handlers
}), [
  handleWorkspaceConnected,
  handleThreadStarted,
  // ... stable callback deps only
]);

useAppServerEvents(handlers);

🧪 Verification Steps

1. Profile with React DevTools:

   • Check "Highlight updates when components render"
   • Look for rapid re-renders in thread/message components

2. Monitor event listeners:

   // In WebKit console
   window.addEventListener = console.log;

3. Add logging to subscribe/unsubscribe:

   // In events.ts
   const subscribe = (onEvent: Listener<T>): Unsubscribe => {
     console.log(`[events] Subscribing to ${eventName}, total: ${listeners.size + 1}`);
     listeners.add(onEvent);
     // ...
   };

📈 Expected Results After Fix

Metric	Before	After
WebKit CPU	60-75%	5-10%
WebKit RAM	1.0-1.7GB	200-400MB
UI Lag	500ms-2s	<100ms
Event Listeners	Growing	Stable (1-3)

🎯 Priority

CRITICAL - This makes the app unusable on systems with <32GB RAM and causes rapid battery drain on laptops.