Charge Limit Apps Broken on macOS 27? AlDente, batt and Fixes

You set your MacBook to stop at 80 percent years ago, and it has been quietly doing that ever since. Then you upgraded to macOS 27 Golden Gate, glanced at the menu bar a few hours later, and the battery read 100 percent. Your charge-limit app still shows a green icon and a friendly "limit reached" message, but the Mac has plainly ignored it. This is not your imagination and it is not a misconfiguration. Apple changed the low-level controls that tools such as AlDente, batt, Battery Toolkit and the battery command line tool depended on, and the developers of those tools are still catching up. This guide explains what actually changed, what each project has said in public, which parts of the story are confirmed and which are only rumour, and what to do today: switch to the limit that is built into macOS, remove old helpers safely, and keep an eye on real battery health with numbers instead of guesses.

Key Takeaways

• The symptom is real and documented: AlDente users on macOS 27.0 and 27.0.1 report Macs charging past their limit, and both the battery and batt projects document that their charge-control keys stopped working on macOS 27.
• The cause is on Apple's side, not yours: according to developer reports on GitHub, the SMC keys these tools used to pause charging were removed, emptied or locked behind a private entitlement. That is a developer-reported finding, not an Apple statement.
• The built-in Charge Limit is the safe answer: on Apple silicon Macs running macOS Tahoe 26.4 or later, System Settings > Battery > the info button next to Charging offers a limit between 80 and 100 percent, and Apple supports it.
• Do not use the adapter-cutoff hacks casually: the maintainer of the battery project rejected an adapter-disable fix because it can cause constant micro-cycling, and the batt project ships a similar mode only as an opt-in.
• Clean up old helpers: a stale privileged helper can outlive the app that installed it. Quit the app, set it back to 100 percent, uninstall its daemon properly, and only then rely on Apple's setting.
• The "limit resets after restart" claim is unverified: it appears in roundup articles without a primary source. Check it yourself after a restart, and here is how.

What Actually Broke: The Timeline

The story did not start on release day. It started in the developer betas, and the public record on GitHub lets us reconstruct it fairly well. Everything below is drawn from public issue and pull request pages that I opened while writing this article. None of it is an Apple statement, because Apple has not documented these internals.

Date (2026)	What happened	Source
Jun 9	An AlDente Pro user on a MacBook Air M3 reports on macOS 27 developer beta that the 78 percent limit is not held, the battery reaches 94 percent, and automatic discharge misbehaves	AlDente issue 1771
Jun 13	Another report on a MacBook Pro 14-inch M1 Pro: "EC charge control does not work at all"	AlDente issue 1775
Jul 10	A contributor opens a pull request for the battery project using new firmware keys on macOS 27 beta 3	battery PR 469
Sep 2	A batt issue reports that on beta 4 and later the charge-control keys are gated, "likely behind an entitlement check"	batt issue 152
Sep 10	AlDente Pro 1.39.1 on the macOS 27 release candidate shows contradictory status messages and does not enforce a 56 percent limit	AlDente issue 1817
Sep 14	macOS 27 Golden Gate ships	see our release-day update guide
Sep 16	A battery pull request describing the removed keys and an adapter-cutoff workaround is closed by the maintainer	battery PR 478
Sep 17 to 19	Two more battery pull requests propose using macOS's own charge limit	PR 479, PR 480
Sep 24	batt merges an opt-in adapter mode for gated macOS 27 firmware	batt PR 154
Sep 29	Fresh AlDente reports, including one on macOS 27.0.1 with AlDente Pro 1.39.4, of Macs charging past the limit	issue 1840, issue 1841

Two things stand out. First, the breakage was visible for more than three months before the final release, so this is not a surprise regression from a late build. Second, macOS 27.0.1 did not repair it: the report on issue 1840 is from a Mac running 27.0.1.

Why Third-Party Charge Limiters Worked Before

To see why they stopped, it helps to understand what they were doing. A MacBook is not a phone that simply stops taking current when a percentage is reached. The battery, the charging circuit and the System Management Controller (SMC) cooperate, and the operating system normally lets Apple's own firmware decide when to charge.

Third-party tools took advantage of a gap. The SMC exposes many small named values called keys, each a four-character code. Some of them, historically, told the charging hardware to stop pushing current into the battery while still letting the Mac run from the adapter. Names that appear in the developer reports include CH0B, CH0C, CHTE, CH0I and CH0J. An app ships a small privileged helper, a background process running as root, that writes those keys when the battery reaches your limit and clears them when it falls below a lower threshold. That is why these apps ask for an administrator password at install time and why they keep working in the background after you close the window.

The important point is the word "privileged". These tools were not using a public, supported interface. They were writing to hardware controls that Apple never documented for third parties. That worked for years, but it always carried the risk that Apple would move the controls, and the reports suggest that is exactly what happened in macOS 27.

What Changed in macOS 27, According to Developers

The most detailed public descriptions come from three places: the write-up of the battery pull request 478, the README and issue 152 of the batt project, and the README of a community fork of Battery Toolkit for macOS 27. They agree on the outline and differ in some specifics, which I will flag.

The legacy keys are gone or empty

According to the battery pull request 478, the keys CHTE, CH0B, CH0C and CH0I returned "no data" on macOS 27, leaving only CHIE responding. The Battery Toolkit macOS 27 fork says the same keys plus CH0J are absent from the SMC index, while CHIE and ACLC remain readable. In batt issue 152 the reporter describes a slightly different state: CH0B, CH0C and CHTE still exist but as zero-size placeholders. "Removed" and "hollowed out" both end with a tool that cannot pause charging.

The newer firmware keys are locked

The obvious next idea was to use newer keys named bfD0, bfE0 and bfF0, which appear to be tied to firmware-managed charge limits. The Battery Toolkit fork reports that they show up in the index but return a not-found result with zero size on its test machine, a MacBook Pro with an M3 Pro. Issue 152 reports that every operation on them fails with error code 0xe00002c1, which is the IOKit "not privileged" error, even when running as root. There is a nuance here. The July pull request against the battery project reported that these keys worked on beta 3, and reviewers later found the keys were not present on an M4 MacBook Air running 27.0. So the behaviour appears to differ by hardware and by build, which is one reason different users see different things.

Where the control moved

Issue 152 makes a specific claim: the functionality moved into a private "SOC limit" subsystem inside powerd, reachable only by a process holding the private entitlement com.apple.private.iokit.soc-limit. If that is right, it explains why root is not enough. On modern macOS, being root does not grant entitlements. A third-party app cannot simply request one, because private Apple entitlements are only honoured for binaries signed by Apple.

I want to be careful here. This is one reporter's analysis on a GitHub issue, and I have not seen Apple confirm it. What is confirmed by several independent sources is the practical outcome: the old switch is gone, and the new one is not available to ordinary helpers.

The Apple Built-In Limit, Explained Properly

The best news in this whole story is that you do not need a third-party tool to cap charging on a current Apple silicon MacBook. Apple's support page About Optimized Battery Charging and Charge Limit on Mac describes two separate features, and mixing them up causes a lot of confusion.

Feature	What it does	Requirement per Apple
Optimized Battery Charging	Uses machine learning to delay charging past 80 percent when it predicts you will stay plugged in for a long time. Occasionally charges to 100 percent to keep the battery estimate accurate.	macOS Big Sur 11 or later
Charge Limit	Sets a custom maximum charge between 80 and 100 percent.	macOS Tahoe 26.4 or later, and a Mac with Apple silicon

How to set it

Apple's steps are short. Open the Apple menu, choose System Settings, click Battery in the sidebar, click the info button next to Charging, choose a Charge Limit between 80 and 100 percent, and click Done. MacRumors reported the options as 80, 85, 90, 95 and 100 percent when the feature appeared in the 26.4 beta. Apple's own Mac battery settings guide summarises it as a way to "preserve the lifespan of your battery by limiting how much your battery charges to". The settings location can vary slightly by Mac model and macOS version, so if the info button is not where you expect it, look in the Battery pane for the Charging row.

How it behaves

Per Apple's page, the Mac charges to within a few percentage points of the limit, then stops and shows "Charged to [limit]" in the battery status menu. If the charge falls by more than 5 percent while you are plugged in, charging resumes and again stops within a few points of the limit. Two consequences matter in practice:

• The stopping point is approximate. A limit of 80 may rest at 78 to 82. That is Apple's wording, "within a few percentage points", not a bug.
• There is a deliberate override. Choosing "Charge to Full Now" from the battery status menu charges to 100 percent for that occasion. This is the supported way to top up before a trip.

For a wider walk-through of the setting, including the 26.4 introduction, see our earlier Mac battery charge limit guide for macOS Tahoe. That article was written in the 26.4 beta period, so where its wording differs from Apple's support page, prefer Apple's.

Intel note

Apple lists Apple silicon as a requirement for Charge Limit, so Intel MacBooks only get Optimized Battery Charging. I could not verify how third-party tools behave on Intel Macs under macOS 27; check the compatibility checker and your tool's documentation.

Per-App Status Table

This table reflects public pages as I read them on 30 September 2026. Statuses change quickly, so treat it as a snapshot and click through before you act. "Reported" means a user report or developer comment exists, not that the vendor has confirmed it.

Tool	Status on macOS 27	Evidence and date
AlDente (Free and Pro)	Multiple user reports of charging past the limit; no developer reply visible on the newest issues	Issues 1840 and 1841 opened Sep 29 (Pro 1.39.4 on 27.0.1, Free 1.39.4 on 27.0); earlier reports since June. The AlDente FAQ says that starting from 1.38 only macOS 12 Monterey through macOS 27 Golden Gate are supported
batt (charlie0129)	Native firmware-limit path documented; opt-in adapter mode merged	README describes a section for macOS 27-era firmware; adapter mode merged Sep 24 in PR 154. Issue 152 reports keys gated
battery CLI (actuallymentor)	Upstream not yet updated for macOS 27 as of the pages I read	PR 478 closed; PRs 479, 480 and 469 open as of the pull request list I read
Battery Toolkit (mhaeuser)	Upstream repository archived on 21 March 2026	Read-only repository page. A separate community fork targets macOS 27 for one tested machine
Battery Toolkit macOS 27 fork	Works by driving Apple's own limit, on the author's tested Mac only	Fork README: personal project, unmaintained, needs building with your own signing certificate

A few notes on this table. The AlDente FAQ states its own compatibility range but does not, in the text I read, say the charge limit works on 27; the issues suggest otherwise for many users. The status of AlDente is also easy to misread because parts of the app continue to work. Reports describe the interface, the menu bar item and the status text behaving normally while the actual charge cutoff does not happen. That is the most dangerous failure mode, because nothing tells you it has stopped.

I could not find an official statement from AlDente's developers about a macOS 27 fix or date. If one exists, it is likely on their site or in their release notes, and I would trust that over any summary here.

What the Workaround Forks Actually Do

Because Apple's limit lives inside powerd, several projects have taken one of three approaches. Understanding them will help you decide whether to trust any of them.

Approach 1: Drive Apple's own limit

The Battery Toolkit fork and the battery pull request 480 both try to use the macOS charge limit rather than SMC keys. The fork does this by writing a preference, mclLimitValue, in the domain com.apple.smartcharging.topoffprotection, and letting PowerUIAgent, which runs as root, hand it to powerd. According to its README, this lets the fork set limits below 80 percent, because the range check only happens in the user interface path. The README is also explicit about the price: it uses undocumented private APIs, modifies a root-owned preference domain, any macOS update can break it, and the path below 80 percent "depends on an unvalidated code path Apple could close".

The battery pull request 480 takes a related route through a private client class and reports that limits below 80 percent are refused by firmware, that the limit is enforced by the firmware draining the battery above the limit at roughly 1.5 to 1.9 amps, and that enabling it overrides the user's own macOS limit. Both descriptions come from the pull request authors, are untested by me, and the request has not been merged.

Approach 2: A resident helper

Pull request 479 proposes an opt-in policy owned by a resident helper that holds the current level instead of charging to full. Its author reports holding an M3 Pro at 87 percent for 250 seconds and lists sleep, wake and reboot behaviour as unverified. That is an experiment, not a finished feature.

Approach 3: Cut the adapter

Pull request 478 tried to inhibit the power adapter itself. The maintainer's objection, as summarised on that page, was that disabling the adapter makes the Mac run from the battery rather than pass power through, forcing continuous micro-cycling that defeats the point of protecting the battery. One commenter put it as "When you disable the adapter the mac starts to work on battery, while we want a power pass through" on 16 September. The author acknowledged the flaw.

The batt project took a more measured route: adapter mode, merged on 24 September, is opt-in, and according to that pull request's description it "cuts wall power at the upper limit and restores it at the lower limit". Its own notes describe about one equivalent extra cycle per day on a 66 Wh battery in the tested case, argue that shallow cycling is gentler than sitting at high charge, and admit that it only enforces the limit while the Mac is awake. That last caveat is important. A laptop that sleeps overnight on the charger is exactly the case where the built-in firmware limit does better.

My recommendation

For nearly everyone, none of these forks is better than the setting Apple ships. They exist for people who need a limit below 80 percent, want calibration or discharge features, or run scripted fleets. If that is not you, use System Settings and skip the risk of a privileged, unsupported helper.

What To Do Right Now: A Step-by-Step Plan

Step 1: Check whether your Mac is actually over-charging

Look at the battery menu bar item or click the battery icon. If the Mac is plugged in and above your intended limit, it is probably not being held. To confirm without third-party tools, use Apple's own data:

# Read the current percentage and whether AC power is connected
pmset -g batt

# Show the power source and battery details Apple exposes
system_profiler SPPowerDataType

Both commands only read information. They change nothing. pmset -g batt prints the charge percentage and whether the Mac is on AC power and charging or "charged". system_profiler SPPowerDataType prints the battery information, including cycle count, condition and, on many Macs, maximum capacity. The exact field names differ by model and macOS version, so read what your Mac prints rather than looking for a specific string.

Step 2: Turn off the third-party limit first

Before you touch Apple's setting, stop the tool from fighting it. AlDente's own FAQ says to set the charging limit back to 100 percent, wait 30 seconds for the change to take effect, quit the app, and then delete it. If you plan to keep using an app that has a native-limit mode, follow that project's documentation instead.

The reason to do this first is that a helper that still believes it is in control can leave the charger in a state you cannot see. Handing control back cleanly reduces the chance of odd behaviour.

Step 3: Set Apple's Charge Limit

Open System Settings > Battery, click the info button next to Charging and choose a limit. Which one? Apple's support page says only that the limit is a custom value from 80 to 100 percent. It does not tell you which value is best. A common reasoning is that 80 percent is the most conservative, 90 is a reasonable compromise if you occasionally unplug and go, and 100 percent turns the cap off. Choose based on how you use the Mac, and change it whenever your day changes.

Step 4: Optimized Battery Charging

On the same screen, Optimized Battery Charging is a separate toggle. AlDente's FAQ recommends turning it off while AlDente is in control. Apple's pages I read do not say you must disable it when using Charge Limit, so leaving it on is a reasonable default. If you see odd "Charging On Hold" messages, try each toggle on its own.

Step 5: Restart once and verify

Restart the Mac, plug it in, and confirm the limit is still set in System Settings. This matters because of the claim discussed in the next section. It takes a minute and settles the question for your machine.

Does the Built-In Limit Reset After a Restart?

You will see this claim in roundups. Some articles say the 80 percent limit "resets to 100% after each restart" in Golden Gate. I tried to trace it. The MacPaw guide says "Some users have reported that the 80% charging limit resets to 100% after each restart", and offers no source. I also opened the OSXDaily battery tips article that some summaries cite, and its text, as I read it, did not discuss the charge limit at all. I found no primary forum thread, Apple statement or bug report from the release itself.

There is one more relevant statement, from a competitor. The AlDente FAQ says that "the macOS charge limit is also not persistent when the MacBook is turned off." That is a vendor's claim, and the vendor sells a competing product. Apple's support page does not mention persistence in the text I read, and the MacRumors report on the feature does not address it either. So this stays in the unverified column.

What can you do? Test it, which is easy:

1. Set the limit to a value you will recognise, such as 85 percent.
2. Do a full restart, not just a sleep.
3. Open System Settings > Battery > the info button next to Charging and read what it shows.
4. If it has reverted, note your Mac model, the macOS build and whether you use Optimized Battery Charging, and send that to Apple with Feedback Assistant. A confirmed reset is a bug worth reporting.

Also keep in mind a separate cause of confusion. Even a working limit is only a target within a few points, and it resumes charging after a 5 percent drop, per Apple. Seeing 95 percent on a Mac set to 90 is not the same as a reset.

Cleaning Up Old Charge-Limit Helpers Safely

If you installed one of these tools, part of it may still be running as root even after you drag the app to the Trash. That matters now for two reasons. A helper that no longer works can be harmless, but one that half-works might still try to write to hardware controls; and helpers are persistent software running with high privileges, which you should not keep around without a reason.

Do this in order and stop if anything looks unfamiliar.

Use the tool's own uninstaller where one exists

The right way to remove a privileged helper is the developer's uninstall path. Documented options I verified:

• batt: for a script or manual install, run sudo batt uninstall, then remove the config and binary; for a Homebrew install, sudo brew services stop batt then brew uninstall batt; for the GUI version, use "Uninstall Daemon..." in the app. Per its README the manual install registers the launch daemon at /Library/LaunchDaemons/cc.chlc.batt.plist.
• battery (actuallymentor): run battery uninstall. The README describes this as enabling charging, removing the smc tool and the battery script.
• AlDente: set the limit back to 100 percent, wait 30 seconds, quit, and delete the app, per its FAQ. The FAQ text I read does not describe a separate helper removal step, so use the in-app options if present and check the sections below.
• Battery Toolkit: I did not find a documented uninstall command in the pages I read. Check the app's own menu for an option to remove its background service before deleting the app.

Inspect what is left, read-only

These commands look but do not change anything.

# Third-party launch daemons (privileged background services)
ls -l /Library/LaunchDaemons

# Privileged helper executables installed by apps
ls -l /Library/PrivilegedHelperTools

# Any sudoers drop-ins added by command line tools
ls -l /etc/sudoers.d

Look for names that match the tool you installed, for example a file starting with cc.chlc.batt for batt. If something matches an app you have already removed, it is a leftover. If you do not recognise a file, do not delete it; search for its name first.

You can also check Login Items & Extensions in System Settings > General. Modern macOS lists background items there with the app that registered them, and you can switch them off with a toggle. That is a reversible first step. The AlDente issue tracker includes a report of duplicate background items with the same name on macOS 27, so do not be surprised if you see two entries.

Removing a leftover daemon

If the developer's uninstaller is gone and you have identified a leftover launch daemon for an app you no longer use, the standard sequence is to unload it, then delete the file. The example below uses batt's documented path. Substitute only a path you have verified belongs to a tool you installed.

# Stop and unload the daemon (this does not delete anything)
sudo launchctl bootout system /Library/LaunchDaemons/cc.chlc.batt.plist

# After confirming it is stopped, remove the plist
sudo rm /Library/LaunchDaemons/cc.chlc.batt.plist

To undo the first command, you would have to reinstall the app, so only run it if you truly want it gone. If a command reports "No such file or directory", the item was already removed and nothing more is needed. Restart afterwards.

What not to do

• Do not delete files in /Library/LaunchDaemons or /Library/PrivilegedHelperTools by wildcard. Apple, security tools and other vendors keep files there too.
• Do not run random cleanup scripts posted in forum threads without reading them.
• Do not turn off System Integrity Protection to work around these changes. It is unnecessary here and lowers the protection of the whole system.
• Do not keep two limiters active at once. Two controls that both think they own charging is a recipe for the contradictory behaviour seen in the AlDente reports.

If you use a managed Mac, ask your administrator before removing anything; a management profile may reinstall tools or expect them to exist.

The Battery Health Context: Numbers You Can Check Yourself

The point of a charge limit is a longer battery life. It helps to measure that rather than take it on faith, and macOS gives you what you need.

What Apple says about cycles

Apple's cycle count page says that to see your count you hold Option, click the Apple menu, choose System Information, then select Power under Hardware. It states that most modern MacBooks are designed for 1,000 cycles, and that a battery is "designed to retain up to 80% of its original charge capacity at its maximum cycle count". A cycle is a full 100 percent of discharge added up, not one plug-in event, so using 50 percent twice counts as one.

Reading it from Terminal

system_profiler SPPowerDataType prints battery information, including cycle count and condition, and you can filter it:

# Battery section only, with cycle count and health lines
system_profiler SPPowerDataType | grep -E "Cycle Count|Condition|Maximum Capacity"

The grep only filters the output. If a line does not appear, your Mac does not print it, and that is fine.

For raw hardware values, the battery is exposed in the I/O registry:

# Read-only: dump the smart battery registry entry
ioreg -rn AppleSmartBattery

Community sources, including an Apple Community thread about an M3 Pro MacBook, describe these fields: CycleCount, DesignCapacity (the factory capacity in mAh), AppleRawMaxCapacity (the current full-charge capacity in mAh) and NominalChargeCapacity. A common way to estimate health is AppleRawMaxCapacity divided by DesignCapacity. On Apple silicon the field MaxCapacity reads as a percentage, not mAh. These are third-party descriptions of undocumented fields, so treat the results as a useful estimate, not an official health number. In that same thread, one respondent cautioned that the output of pmset -g rawbatt is not accurate on an M-series Mac. The number Apple shows in System Settings under Battery Health is the one Apple supports for service decisions.

What does the chemistry actually say?

Mac batteries are lithium-ion, and Apple's battery performance guidance is worth reading directly. It calls 62 to 72 degrees Fahrenheit (16 to 22 degrees Celsius) the ideal comfort zone for its devices, warns that ambient temperatures above 95 degrees Fahrenheit (35 degrees Celsius) can permanently damage battery capacity, and for long-term storage recommends charging to around 50 percent and avoiding a full charge or a full discharge, because either extreme can reduce capacity. For MacBooks it gives a wider operating range of 50 to 95 degrees Fahrenheit (10 to 35 degrees Celsius). Apple also says its systems manage charging patterns and temperature, and that features like Optimized Battery Charging adapt to your usage to preserve lifespan.

That is the extent of what Apple states there. It does not give a numeric benefit for a specific charge limit. Broadly, lithium-ion wear is understood to be faster at high state of charge and high temperature, which is the reasoning behind charge limits, but I am not going to quote a lifetime multiplier, because how much a limit helps depends on the cell design, the temperature and the usage. The older 2026 guide on this site quotes figures such as capacity retention after 500 cycles; treat those as rough rules of thumb rather than measured results for your Mac. For a deeper look at power management, see our battery diagnostics guide.

Troubleshooting Common Issues

My Mac still charges to 100 percent with the built-in limit set

First confirm the Mac supports it. Apple lists Apple silicon and macOS Tahoe 26.4 or later. Open System Settings > Battery > info button next to Charging and check that a value below 100 percent is selected. Make sure no third-party helper is still active; go through the cleanup steps above. If you had used "Charge to Full Now" earlier, that was a one-time override. Restart, plug in, and watch the menu bar for the "Charged to" message. If it still ignores a clearly lower limit, collect the macOS build, your Mac model and reproduction steps and file Feedback.

AlDente says the limit is reached but the battery keeps climbing

This matches the reports on issues 1840 and 1841. Quit AlDente, set 100 percent first, and switch to Apple's Charge Limit. Then check whether the helper is still running (see the inspection commands above). Keep an eye on the AlDente issues and release notes for an official update before you re-enable it.

The battery is discharging while plugged in

Some tools use forced discharge or adapter cutoff, which makes the Mac run from the battery even though it is plugged in. The batt documentation notes that on macOS 27-era firmware the Mac may run from the battery when it is above the limit, and one AlDente report describes discharge stopping and restarting unexpectedly. If your Mac drains while connected, remove the tool's daemon, restart, and re-test with only Apple's setting. Separately, a low-wattage charger can look like this too: macOS 26.4 added a slow charger indicator, according to 9to5Mac, and Apple recommends minimum wattages per model.

The Mac is hot and the battery is draining fast after upgrading

That is a different problem: post-upgrade indexing can cause heat and drain for a day or two. See our guide to Spotlight reindexing battery drain in macOS 27 and wait for indexing to finish before judging the limit.

The Charge Limit control is missing from System Settings

Check your Mac and macOS version first. Apple's page requires Apple silicon and macOS Tahoe 26.4 or later. Intel Macs and older macOS versions will not show it. If you are on a supported Mac and macOS 27, update to the latest point release, restart, and look again in System Settings > Battery > info button next to Charging.

A custom limit below 80 percent

Apple's setting stops at 80 percent, and I found no supported way to go lower. Community forks that do it rely on private APIs, as their own README warns.

Managed Macs and fleets

Inventory launch daemons and privileged helpers before pushing macOS 27, use Apple's supported setting where policy allows, and pilot first. I found no documented MDM key for Charge Limit, so do not assume one exists. If a rollback is on the table, see the downgrade assistant.

FAQ

Why did my charge limit app stop working on macOS 27?

According to developer reports on GitHub, macOS 27 removed or locked the SMC charge-control keys these apps write to. The keys either return no data, or fail even for root, and the replacement control sits behind a private Apple entitlement. Apple has not published details, so treat this as the developers' analysis rather than an Apple statement.

Is the built-in Charge Limit safe to rely on?

Yes. It is Apple's own supported feature. Apple's support page says it requires macOS Tahoe 26.4 or later and a Mac with Apple silicon, lets you choose 80 to 100 percent, and lets you override it with "Charge to Full Now". Unlike third-party helpers, it does not depend on unsupported hardware keys, so a future macOS update should not silently break it.

Will AlDente be fixed?

I do not know. As of 30 September 2026, the newest issue reports on GitHub had no developer replies that I could see, and I found no official statement or date. The FAQ lists macOS 27 among supported versions from AlDente 1.38, but users on 1.39.4 still report over-charging. Watch the vendor's release notes rather than relying on roundups.

Does the built-in limit reset to 100 percent after a restart?

Unverified. Some roundup articles say so, without a primary source, and a competing vendor's FAQ claims it is not persistent. Apple's support page does not address it. Test on your own Mac by setting a distinctive limit, restarting, and checking System Settings. If it reverts, report it with Feedback Assistant.

Can I keep using adapter-cutoff modes?

They are opt-in for a reason. The maintainer of the battery project rejected an adapter-disable approach because it can cause constant micro-cycling, and batt documents that its adapter mode adds shallow cycles and only enforces while the Mac is awake. If you need a hard cap for a special case, understand these trade-offs first. For everyone else, Apple's limit is simpler.

How do I check that my battery is healthy?

Open System Settings > Battery and read Battery Health, or hold Option, click the Apple menu and open System Information > Power for the cycle count. Apple says most modern MacBooks are designed for 1,000 cycles and to retain up to 80 percent capacity at that point. Terminal tools like system_profiler SPPowerDataType show the same data.

Do I need to delete my charge limit app?

If it no longer works, yes, uninstall it properly rather than leave a privileged helper running. Use the developer's uninstaller where available, such as sudo batt uninstall or battery uninstall. For AlDente, set 100 percent, wait 30 seconds, quit and delete, per its FAQ. Then inspect launch daemons for leftovers.

Does this affect Intel MacBooks?

Apple's Charge Limit requires Apple silicon, so Intel MacBooks do not have it. Optimized Battery Charging is available from Big Sur onward. I could not verify how third-party tools behave on Intel Macs under macOS 27, so read your tool's documentation, and check that your Mac is supported in the first place.

Conclusion

The short version is that macOS 27 broke a long-standing hack, and the hack's maintainers are still working out replacements. AlDente, batt, Battery Toolkit and the battery CLI were all built on hardware controls that Apple never promised to keep, and the public record shows those controls disappearing or becoming inaccessible over the beta period and into the release. Apple, meanwhile, has shipped a supported Charge Limit that does the most important part of the job for most people: hold the battery below full while the Mac sits on the charger.

So the practical plan is simple. Stop relying on a tool that reports a limit but does not enforce it. Hand control back cleanly, set Apple's Charge Limit under System Settings > Battery, restart once to verify it holds, and remove leftover privileged helpers using the developer's own uninstaller. Measure your battery with cycle count and Battery Health instead of trusting a menu bar icon. Treat sensational claims, including the restart-reset rumour, as open questions until someone shows a reproducible case. And if you want a limit lower than 80 percent, accept that you are stepping outside Apple's supported path.

This situation is still moving. New commits landed on these projects in the last two weeks, and macOS 27.0.1 did not change the picture for the reports I read. I will refresh the status table as the projects respond.

Related reading: Mac battery charge limit in macOS Tahoe 26.4, Tahoe battery diagnostics guide, Tahoe battery optimization advanced guide, battery drain fix guide, Golden Gate release-day update guide