MagSafe LED does not reflect user-defined charging limit (optimized battery charging)

I recently noticed a UX inconsistency while using the battery charge limit feature on my MacBook with a MagSafe charger.

Have you filed a bug on this and, if so, what's the bug number?

Has anyone else observed this behavior, or is there any existing workaround?

I haven't looked into the issue in detail, but I wouldn't expect there to be any sort of workaround. My guess is that the reason the issue exists at all is that the LED is being controlled at a VERY low level, possibly through direct interactions in the charging hardware and not through the normal "system" (so the machine doesn't have to actually be "on"). That would also mean it's largely outside of the system’s normal management/configuration.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Yes, I’ve filed this as feedback — FB22468514.

Perfect, thank you. I can't comment on our release plans or schedules, but this is something I do expect us to address.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Perfect, thank you. I can't comment on our release plans or schedules, but this is something I do expect us to address.

...and this should be fixed in the most recent beta seed, macOS 26.5 beta 3 (25F5058e). More specifically:

• The light should now turn green when the device reaches the charging limit.

• The light should now turn back to amber if/when power drain causes charging to resume.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I would love to hear how you solved it;😊

I would love to hear how you solved it;😊

Truth be told, it's actually pretty simple. You've been thinking of the LED as part of the "charger", but that's not how it actually works. With a bit of searching, you can find teardowns and pinout descriptions of the MagSafe connector, and the "trick" here is that one of those pins uses a very simple and low-power protocol to pull identifying data about the adapter/cable... and to control the charging LED.

That process is essentially independent of the entire charging process and, in fact, I believe it's possible to light up the LED without the cable even being attached to power. In other words, the LED is more like a light bulb that happens to be "attached" to the charging cable, not an integral component of the actual charging process. Theoretically, the Mac could make the LED do anything it wants, but the hardware is involved is so slow[1] that making it blink like a strobe light is probably impossible.

In any case, with all that context, the fix here was simply adding an additional check into the code that sets the LED color so that it accounted for virtual charging limit, not just the true physical state.

[1] There's no reason for it to be fast, particularly since the MagSafe handshake process is intentionally fairly slow for safety reasons.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I’d like to offer a different perspective on the MagSafe LED change that shipped in macOS 26.5. Previously, the LED stayed amber while the battery was below 100%, even when a Charge Limit (e.g. 80%) was active and charging had stopped. Green only appeared at a true 100% charge. After 26.5, green now means “charge limit reached.”

While the new behavior might be more consistent with the system’s internal state, it removes a useful visual distinction for users who deliberately keep a limit set for battery longevity:

• Amber → safe to leave plugged in (either still charging or holding at the limit)
• Green → truly at 100% (time to unplug if desired)

With the current behavior there is no longer a glanceable way to know whether the Mac is holding at the user-set limit or has been allowed to reach 100% (at the periodic calibration charge). Would it be possible to add a preference that lets the user choose when the LED turns green?

1. Green = charge limit reached (current 26.5 behavior)
2. Green = true 100% only (pre-26.5 behavior)

This would preserve the improved clarity for those who prefer the new mapping while restoring the previous signal for those of us who relied on it. I’ve already submitted this as Feedback, but wanted to surface the opposing use case here as well.

Thanks for considering it.

I’d like to offer a different perspective on the MagSafe LED change that shipped in macOS 26.5. Previously, the LED stayed amber while the battery was below 100%, even when a Charge Limit (e.g. 80%) was active and charging had stopped. Green only appeared at a true 100% charge. After 26.5, green now means “charge limit reached.”

While the new behavior might be more consistent with the system’s internal state, it removes a useful visual distinction for users who deliberately keep a limit set for battery longevity:

This is a great example of a bug where we don't find out how many people liked the old behavior until we change the behavior because some other people complained...

With the current behavior, there is no longer a glanceable way to know whether the Mac is holding at the user-set limit or has been allowed to reach 100% (at the periodic calibration charge). Would it be possible to add a preference that lets the user choose when the LED turns green?

Maybe? It would need to be a system-wide setting (not per user), as the power management system has to operate independently of most of the lower-level system, not just user sessions. However, the bigger complication is that this sort of setting needs to be accessible "all" the time, even before the first unlock (post-reboot) has occurred. That means it probably needs to be stored in NVRAM, along with the UI work to let the user change the setting.

That's far more work than that change that was made in 26.5, where all that really changed was the existing driver managed the bulb based on information it already had.

I’ve already submitted this as Feedback, but wanted to surface the opposing use case here as well.

What’s the feedback number? I'm not sure we'll be able to add a setting for this, particularly in the near future, both because it's more work than it seems and because having a setting for something creates its own problems, namely:

• Having a setting means the behavior isn't consistent, which means the LED’s meaning is no longer something you can rely on.

• Each additional setting makes the entire setting system more complex and overwhelming, something that’s obviously already a challenge.

Having said that, it’s possible there might be a compromise or alternative option that would handle your concerns as well.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware