For months, I battled a persistent and damaging issue on my Mid 2015 MacBook Pro — a workhorse of a machine that, even at nearly 10 years old, continues to run exceptionally well with a 2.5GHz Quad-Core i7, 16GB RAM, 1 TB SSD and macOS Monterey 12.7.6.

The system process configd would regularly consume 100% of the CPU. The fans screamed. The laptop baked. Performance tanked. Worst of all — two batteries failed completely during the years this bug went undiagnosed.

---

A Machine with a Backstory

This MacBook Pro actually replaced an almost identical model (with a 500GB SSD) whose keyboard had begun to fail. That original machine is now used as a secondary workstation — mostly plugged in with external monitors, keyboard and mouse and of course, rarely moved.

However, the replacement system was set up via migration from the older Mac, meaning all settings, preferences, and low-level cruft came with it. It’s entirely possible this bug — and the problematic plugin behind it — exists on the secondary machine too, simply hiding in the shadows because that Mac rarely gets unplugged or stressed.

---

A Hunch from the Past

Throughout the troubleshooting, I had a nagging feeling: years ago, I’d installed a PPP-based VPN service, and I couldn’t shake the idea that something related had survived the years. That memory — almost dismissed — turned out to be the smoking gun.

---

All the Fixes That Didn’t Work

Before getting to the actual solution, I tried everything:

• Resetting network preferences

• Disabling IPv6

• Safe Mode diagnostics

• launchctl unloads

• Cleaning out /SystemConfiguration

• Monitoring via top and Activity Monitor

Nothing worked. The issue was like digital rot — persistent and invisible.

---

Enter ChatGPT

Eventually, I turned to ChatGPT for deeper insight. Together, we sampled the configd process and analysed its call stack. That led us to the true culprit:

PPPController.bundle — a legacy dial-up/VPN plugin, long deprecated but still loading in the background.

Despite not being used in years, it was triggering configd into a CPU loop, damaging system performance and hardware.

---

macOS Protections (and How to Work Around Them)

macOS uses System Integrity Protection (SIP) and Signed System Volumes (SSV) to protect core files. To disable this plugin, you must bypass those protections temporarily.

---

The Fix (Finally)

WARNING!

DO NOT ATTEMPT ANY OF THE FIXES BELOW WITHOUT CONSULTING A TRAINED APPLE EXPERT! YOU ARE FIDDLING WITH THE WORKINGS OF A COMPUTER AND RISK PERMANENTLY LOSING THE CONTENTS OF YOUR HARD DRIVE. PLEASE, PLEASE!!! TAKE A FULL BACKUP BEFORE ATTEMPTING ANYTHING LIKE THIS.

IT TOOK SEVEN ATTEMPTS TO FIX THIS PROBLEM WITH THE ASSISTANCE OF CHATGPT, SO IT FAILED SIX TIMES BEFORE THE ISSUE WAS RESOLVED.

Step 1: Reboot into macOS Recovery (Cmd + R)

Open Terminal from the menu.

Step 2: Disable protections

Reboot again into Recovery after this.

Step 3: Mount the system volume

Step 4: Disable the plugin

Step 5: Bless the system snapshot

---

Confirming It Worked

• top -o cpu showed configd no longer topping the chart

• configd -v | grep -i ppp showed nothing — the plugin was gone

• The Mac ran cooler, quieter, and battery health stopped declining

---

Re-enabling Protections

After verifying stability:

Then reboot normally.

---

Final Thoughts

This wasn’t your average support task. It took two dead batteries, countless failed attempts, a hunch from years back, and finally the help of ChatGPT to trace configd’s madness back to a plugin that had long outlived its purpose.

If you’ve ever migrated from an older Mac, especially one where you’d used PPP-based VPNs or dial-up tools, this issue may be lurking silently in your system too — especially if that system is mostly docked or plugged in. For me, it nearly cooked a great machine.

Now? My Mid 2015 MacBook Pro is back to being a quiet, powerful daily driver — and I intend to keep it that way.

Have a similar story? Reach out  or connect with me on social media. Let’s keep our ageing tech running better than new.