DEV Community

Pavan Kumar Sadashiv
Pavan Kumar Sadashiv

Posted on

How I Tracked Down and Fixed Mystery Overheating & CPU Leaks on macOS

#macos #devops #productivity #tooling

If you use a Mac—especially a fanless MacBook Air—you know the feeling: suddenly, the bottom chassis gets uncomfortably warm, your battery percentage starts tumbling off a cliff, and yet you aren't doing anything heavy.

Activity Monitor often hides what sub-workers are actually doing, especially when Electron apps, browser tabs, and background linters spawn dozens of helper processes.

Here is a practical, terminal-first breakdown of how I diagnosed and fixed runaway CPU spikes (totaling over 500% CPU across multiple cores) without rebooting or losing unsaved workspace work.

1. Spotting the Culprits from Terminal

When a Mac starts heating up, the quickest way to inspect the true per-process CPU consumption is using ps ordered by CPU percentage:

ps -Aceo pid,pcpu,pmem,comm -r | head -n 15
Enter fullscreen mode Exit fullscreen mode

The Output

In my case, the culprits immediately showed up:

  PID  %CPU %MEM COMM
80646 251.9  5.5 Google Chrome Helper (Renderer)
 2500  99.7  0.0 Antigravity IDE Helper (Plugin)
83817 147.9  5.6 java
  419  63.4  0.9 WindowServer
Enter fullscreen mode Exit fullscreen mode

We had three distinct issues running simultaneously:

  1. Google Chrome Renderer maxing out 2.5 CPU cores (~252%).
  2. An IDE Extension Host pinned at ~100% CPU for multiple days.
  3. A background Java process consuming ~148% CPU.

Let's break down how to fix each without blowing up your workflow.

2. Fixing Runaway Chrome Tabs (Without Crashing the Browser)

Modern browsers run every tab and extension in a separate renderer process (Google Chrome Helper).

When a rogue tab's JavaScript gets stuck in an infinite loop or heavy DOM animation, it doesn't crash Chrome—it just silently cooks your CPU.

Diagnosing the Tab

To find which tab or extension maps to the high-CPU PID:

  • In Chrome, press Shift + Esc to open Chrome's Task Manager.
  • Sort by CPU to spot the exact tab.

The Surgical Kill

If you already have the PID (e.g. 80646), you can kill just that single renderer tab from your terminal:

kill 80646
Enter fullscreen mode Exit fullscreen mode

What happens: Only that single crashed tab shows an "Aw, Snap!" message. All your other windows, tabs, forms, and sessions remain completely untouched.

3. The Zombie IDE Extension Host (PID at 100% CPU)

If you use VS Code, Cursor, or any Electron-based IDE, extensions run inside an isolated process called the Extension Host (...Helper (Plugin) or code-extensionHost).

Inspecting process 2500:

ps -p 2500 -o pid,%cpu,etime,args
Enter fullscreen mode Exit fullscreen mode 
  PID  %CPU     ELAPSED ARGS
 2500  99.1 02-15:50:01 /Applications/... Helper (Plugin)
Enter fullscreen mode Exit fullscreen mode

This extension host had been spinning at 99% CPU continuously for 2 days and 15 hours! It was an orphaned process left behind from a previous window.

Fix A: The Clean In-Editor Restart

If the extension host belongs to your current active window, don't restart the app or reboot your machine:

  1. Open the Command Palette (Cmd + Shift + P).
  2. Search and run: 
   Developer: Restart Extension Host
Enter fullscreen mode Exit fullscreen mode

This restarts the language tooling in ~1 second with zero loss of editor tabs, unsaved buffers, or split layouts.

Fix B: Terminating the Zombie Process

If it's an orphaned process from a closed window that refused to terminate:

kill -9 <PID>
Enter fullscreen mode Exit fullscreen mode

4. Background Language Servers & Linters (The 200% Java Spike)

Once the IDE extension host was restarted, another spike appeared:

PID   %CPU  COMM
86820 218%  java (.../sonarsource.sonarlint-vscode/...)
Enter fullscreen mode Exit fullscreen mode

Many developer extensions—especially full static analysis tools like SonarLint, Language Support for Java, or heavy LSP linters—trigger a full-workspace indexing pass upon startup.

If you are working in large repositories containing node_modules, build artifacts, or vendored directories, the indexer can hammer your CPU trying to parse thousands of generated files.

The Fix

  1. Exclude heavy directories: In your editor settings, configure the linter's file exclusions: 
   "sonarlint.files.exclusions": [
     "**/node_modules/**",
     "**/dist/**",
     "**/build/**",
     "**/.git/**"
   ]
Enter fullscreen mode Exit fullscreen mode
  1. Temporarily Disable Heavy Linters: If you're on battery or working on an un-indexed project, open the Extensions pane (Cmd + Shift + X), search for the extension, and click Disable (Workspace).

Quick Reference Cheat Sheet

Symptom Quick Terminal Command Action
Check Top CPU Processes `ps -Aceo pid,pcpu,pmem,comm -r \ head -n 10`
Inspect a Process Runtime ps -p <PID> -o pid,%cpu,etime,comm Check how long it's been pegged
Kill a Single Chrome Tab kill <PID> Tab crashes with "Aw Snap", rest of browser survives
Restart IDE Extension Engine Cmd + Shift + P → Restart Extension Host Drops IDE CPU to 0% with 0 data loss
Force Kill Orphaned Process kill -9 <PID> Immediate termination

Wrapping Up

A hot laptop isn't always caused by what you are actively doing—often it's caused by what was left running hours or days ago.

With a simple ps check and surgical process signals, you can instantly tame background heat and reclaim your battery life without restarting your Mac or interrupting your flow.

Have you encountered rogue extension hosts or browser helper processes? What tooling do you use to keep background CPU in check? Let me know in the comments below!

Top comments (0)