amfid on Mac: the code signature checker, why it is busy, and why you leave it alone

What amfid does

AMFI stands for Apple Mobile File Integrity, a name inherited from iOS, where it was built first. It is the mechanism that makes code signing mean something. Inside the kernel, a component checks the signature of every executable as it is loaded. When the kernel needs help, for example to validate a signature against Apple's certificate chain or to check a provisioning profile, it asks a small user-space daemon: amfid. That daemon answers yes or no, and the kernel either lets the program run or kills it.

This happens for every app you open, every helper an app launches, every command-line tool, every plug-in. On a normal day that is thousands of checks, each one taking a fraction of a millisecond, which is why amfid is nearly always idle in Activity Monitor. It is in the same family as syspolicyd, which enforces Gatekeeper on first launch, and trustd, which evaluates certificates. Eclectic Light's walkthrough of how macOS launches an app shows the sequence: the kernel loads the code, AMFI validates the signature, Gatekeeper and XProtect run their checks on first launch, and only then does the app's window appear.

amfid also protects itself. It runs as root, is launched by launchd at boot, lives on the sealed system volume, and is one of the components that System Integrity Protection covers. There is no user setting for it.

What normal looks like

amfid is a short-burst process. The pattern looks like this:

There are few forum threads about amfid on its own, and that is telling. It is one of the quietest daemons on the system. When people do mention it, it is nearly always alongside syspolicyd, trustd or XProtectService in the first day after an update, or during a build that launches a huge number of small binaries.

Why amfid is using CPU right now

1. A macOS update just installed. Every system component and app is validated fresh on its next launch. The first hour is busier than usual and then it is quiet.
2. You installed or updated something huge. Xcode, a game engine, a creative suite, or a package manager pulling in hundreds of tools. Each new binary gets a full signature validation the first time it runs.
3. A build or test run is in progress. Compilers, linkers and test runners launch thousands of short-lived processes. Each one is checked. amfid shows as busy for the length of the build and stops when it does.
4. A certificate check is slow. Validating some signatures involves trustd and the network. On a VPN, a captive portal or a flaky connection, each check waits, launches hang, and amfid appears busy while it is mostly waiting.
5. The disk is slow or nearly full. Signature validation reads the executable. On a full or failing drive those reads crawl, and so does amfid.
6. An app with a broken signature keeps relaunching. A helper whose signature no longer validates gets killed by the kernel and restarted by its parent, over and over. Each attempt is a check. Quitting the parent app ends it, and updating that app fixes it properly.

Is it safe to quit amfid?

No. amfid runs as root, so Activity Monitor asks for your password, and launchd brings it back within a second. During that gap, any app trying to launch has no one to validate its signature and the launch can fail outright. If the busy period was caused by an update or a build, the new amfid simply continues the same work. There is nothing to gain and a small chance of a failed app launch to lose.

It is also a core security component. The techniques that disable AMFI require turning off System Integrity Protection and changing boot arguments, which removes real protection from the Mac. That is never the answer to a process using CPU for a few minutes after an update.

Run any name from Activity Monitor through the checker above. amfid lands squarely on leave it.

What to do, in order

1. Ask what just happened

   A macOS update, a big install, or a build running? Then amfid is doing expected work. Give it the hour and open the apps you use once each so their checks are done and cached.

2. Watch whether it is bursty or flat

   Normal amfid activity rises when something launches and falls back to zero within seconds. Watch Activity Monitor for two minutes. Bursts are fine. A flat high line with nothing launching is the thing to investigate.

3. Look at the neighbors

   Sort by CPU. If syspolicyd, trustd or XProtectService are busy at the same time, this is the post-update check-in and it is normal. If a single third-party app or helper keeps appearing and disappearing, that is the relaunch loop; quit that app.

4. Check the network if launches hang

   Disconnect the VPN, or switch to a different Wi-Fi network, and try opening an app again. If it opens instantly, the slow part was the online certificate check, not amfid itself.

5. Free up disk space

   Keep at least 10 to 20 GB free. Signature checks read the whole executable, and a nearly full drive makes every read slow. The free up space guide has the safe steps.

6. Update macOS and the app that is looping

   System Settings, General, Software Update. Then update any app whose helper keeps relaunching; a broken signature is nearly always fixed by the developer's next build.

7. Restart

   A restart clears any stuck validation and warms the caches cleanly on the way back up. If amfid is quiet after the restart, you are done. If launches are still slow for days with plenty of free space and a good connection, reinstalling macOS over the top from Recovery repairs the system volume without touching your files.

When to worry

A busy amfid is the system checking code, which is the behavior you want. These are the situations that merit attention:

• An app you rely on is killed the moment it launches, every time. That is amfid rejecting its signature. Re-download the app from the developer; if it still fails, the developer needs to re-sign it.
• Every app launch stays slow for days after an update with free space and a working network. That can mean a damaged system volume; a reinstall over the top fixes it.
• A process named amfid is running from anywhere other than the system volume. The real one lives at /usr/libexec/amfid. Check the path in the Activity Monitor info panel.

None of these are reasons to disable SIP or AMFI. They are reasons to update, reinstall or replace the app in question.

Because amfid's load is tied to what is launching, the useful record is the timeline: which processes started at the moment amfid rose. Safe to Quit keeps that history for every process, so a burst after an Xcode update and a loop from a broken helper look clearly different.

Look up another process

amfid is rarely alone in the CPU list. Type any other name from Activity Monitor to see what it is and whether it is safe to leave.