Safe mode is an undervalued tool for dealing with a broad range of problems in macOS. Although not a universal panacea, it has several valuable uses, and can be helpful before having to resort to more time-consuming diagnostic procedures. This article explains how to engage your Mac into Safe mode, what it does, and when you should use it. This is based primarily on macOS Sequoia 15.3.2 running on Apple silicon Macs, but does cover Intel models, and much should apply to recent versions of macOS.

Entering Safe mode

Consider first whether you should disconnect some or all non-essential peripherals. If you’re only intending to use Safe mode to flush caches, or to install an awkward macOS update, that shouldn’t be necessary. When trying to diagnose potential problems with extensions, though, it could be beneficial.

Apple silicon Mac

The Mac must be shut down to begin with. Press its Power button and keep it held in until you see its Recovery options loading. Then select the startup disk you want your Mac to boot from, and hold the Shift key. The button underneath that disk icon will change to read Continue in Safe Mode. Click on that button, and your Mac will restart.

Normally, you’ll be asked to log in twice, and initially, at the upper right of the display, the words Safe Boot will be shown in red.

Intel Mac

All you need do with an Intel Mac is start up (or restart) with the Shift key held down until you see the login window. If you have set a firmware password, you’ll need to remove that in Recovery before trying to start up in Safe mode.

Checking

Once your Mac is running in Safe mode and you’ve logged in, check that it really is in Safe mode by opening System Information. Click on Software at the left, and the line Boot Mode should say Safe rather than Normal.

If you can’t start your Mac up successfully in Safe mode, Recovery is your only option, where you might consider reinstalling macOS.

Leaving Safe mode

To leave Safe mode and return to normal mode, simply restart the Mac.

How is it different?

According to Apple’s current description, Safe mode:

• “Prevents certain software from loading as your Mac starts up. This includes login items and extensions that aren’t required by macOS, and fonts that weren’t installed by macOS.”
• “Performs a basic check of your startup disk, similar to the more comprehensive check performed by the First Aid feature of Disk Utility.”
• “Clears some system caches, including font caches and the kernel cache. These are automatically created again as needed.”

Apple warns that some macOS features may not work when in Safe mode. Those could affect “video capture, graphics performance, file sharing, Wi-Fi, accessibility, audio devices and devices connected via USB, Thunderbolt or FireWire.” In practice these seem to vary according to Mac and macOS, making it hard to know what to expect. Most USB and Thunderbolt storage should still work normally, and Time Machine backups should continue as usual when running in Safe mode.

Blocking extensions and customisations

Booting in Safe mode blocks the loading of all third-party kernel extensions, and may delay the loading of some of those provided in macOS. Specifically, those in the Auxiliary Kernel Collection (AKC) aren’t loaded, and any devices or features relying on them won’t be available. All kernel extensions in the main Kernel Collection appear to be loaded normally. If you suspect that your Mac’s problems could relate to a third-party kernel extension, this makes Safe mode an excellent diagnostic test without having to alter Startup Security for an Apple silicon Mac.

Apple adds to that login items, system extensions (the modern replacement for kernel extensions), and fonts not installed by macOS. These are other common causes of compatibility problems, adding to the value of Safe mode.

Checking the startup disk

Older versions of macOS performed extensive checks of both disks and snapshots using fsck_apfs. Apple discontinued those some years ago, because they extended Safe boot time to periods sometimes exceeding half an hour. Since then, checks performed by fsck_apfs don’t include snapshots, and are quick checks rather than a full check-and-repair. As they’re performed after the Data volume in the active boot volume group has been mounted, they only cover a limited range of volumes: from the active boot volume group, only the Recovery and Update volumes are checked, together with all accessible external volumes. Results are written to the fsck_apfs logs at /var/log/fsck_apfs.log and /var/log/fsck_apfs_error.log, and in entries in the Unified log.

Those checks in Safe mode currently appear identical to those made during a normal boot. Accordingly, if you want to perform checks on your Mac’s current boot volume group, you should do so using Disk Utility or fsck_apfs in Recovery mode. Safe mode is no longer a useful tool for performing disk checks.

Deleting caches

Discovering exactly which caches are emptied or deleted isn’t straightforward. Beyond Apple’s two instances of font caches and the kernel cache (which only applies to Intel Macs), none of the caches used by Launch Services appear to be affected by this. Neither does this appear to include other notable caches and hidden data stores, such as those for QuickLook or Spotlight.

macOS updates

Although not mentioned by Apple, one longstanding use for Safe mode is to download and install macOS updates. This may have become less used since updating was re-engineered for Big Sur, but is always worth bearing in mind. A short visit to Safe mode, lasting just a couple of minutes before restarting in normal user mode, can also fix problems discovered after updating or upgrading macOS; if a normal restart doesn’t sort them out, try Safe mode before calling Apple Support.

Safe mode in Apple silicon Virtual Machines

Safe mode is available when running lightweight virtualisation of macOS on an Apple silicon Mac, provided that the host operating system is Ventura or later, which provides the option to start the VM in Recovery mode. Enable that option before starting the VM, then use the normal procedure to restart in Safe mode. When you shut down that VM, remember to disable starting in Recovery before running the next VM.

Good reasons for Safe mode

• To identify and locate problems with third-party kernel extensions.
• To identify and locate problems with third-party system extensions, fonts, login items, and other user customisations, as a quicker alternative to creating a ‘clean’ user account.
• To download and install macOS updates, when they don’t work in normal mode.
• To fix problems following macOS updates, when a normal restart doesn’t help.
• To clear font and other user caches.
• When there are problems preventing booting in normal mode, short of going to Recovery mode.
• As a generic non-destructive panacea.

A kernel panic is completely different from an app crash. When apps suddenly vanish because of a bug or error, everything else should carry on as normal. When your Mac restarts of its own accord, or you find it shut down and have to start it up again, that’s almost certainly a kernel panic, and should be taken seriously.

Kernel panics occur when macOS can’t continue running any more due to severe (software) damage, and its only option is to restart itself in order to resume normal services. When this happens before the login window appears during startup, it normally results in a boot loop, as discussed elsewhere. This article covers the more common situation when a Mac restarts spontaneously and completes login without any further panic occurring.

Virtual machines (VMs) can also suffer kernel panics, as well as causing the host macOS to panic. Those should behave like other panics, although if you’re unlucky the VM might be damaged and unable to restart properly. If that happens, your only option is to try starting that VM up in Recovery, to see if it can be repaired there. If not, and you can’t get it to start up again, you’ll need to trash it and restore its last backup copy.

Save the panic log

Within a minute or so after restarting, a Panic Alert is displayed, inviting you to agree to send the panic log to Apple. Don’t simply agree to that, though, as it’s the only record of what happened. Panic logs used to be saved in /Library/Logs/DiagnosticReports, from where you could open them in Console, but more recently may be found somewhere closer to /var/db/PanicReporter. You therefore need to copy its contents as soon as it appears and before sending it to Apple.

If the alert isn’t already showing the panic log, click on its Report… button, then open a text editor like TextEdit. Copy the whole contents of the panic log into an empty text window and save it somewhere safe before clicking on the button to send the report to Apple. Once you’ve done that, the alert is dismissed and can’t be brought back.

It’s commonly assumed that sending a panic log to Apple means that an engineer will look through it and get back to you with some sort of diagnosis. That isn’t what the report does, though: it’s processed automatically and, while there’s nothing stopping someone at Apple contacting you about it, that simply doesn’t happen. Only by saving a copy of the log could you contact Apple Support and ask for their help. Also consider filing a Feedback report containing a description of what happened and your copy of the panic log, particularly if you have clues as to its cause.

Immediate actions

The three most common reasons for kernel panics are:

• hardware (and device firmware) failure or error,
• kernel extensions,
• conflict with a peripheral.

If you suspect a hardware failure, or wish to rule that out, shut your Mac down once you have captured the panic log, disconnect all non-essential peripherals, and start it up in Diagnostics to run its hardware test routines. If you’re not reassured that all is well, don’t hesitate to get your nearest Apple store or authorised service provider to run their more advanced diagnostics as well.

On Apple silicon Macs, Diagnostics is different in relying on a hidden key combination: start the Mac up in Recovery by holding the Power button, and in the initial Options screen, hold Command-D until the Diagnostics Loader starts. This may require download of the disk image from Apple’s servers before testing can proceed, so a good Wi-Fi connection is important. Once loaded, there’s a hidden option for extended diagnostics that can be triggered by holding the Command-E key combination.

Panics associated with peripherals such as Thunderbolt docks and hubs are best diagnosed by running the Mac without the suspect hardware connected, to test if panics continue. If they do, and you remembered to save panic reports, even if you don’t understand their details you can still compare them to see if they look similar.

Kernel extensions

Third-party kernel extensions are normally found in /Library/Extensions or the app using them, from where macOS stages them into a folder in /Library/StagedExtensions where they’re protected by SIP. Most are only loaded on demand, so the mere presence of an extension there isn’t sufficient evidence to convict it of causing the panics. However, you should become suspicious when a third-party extension is named in the panic log as being part of the chain that may have caused it. Most software that used to rely on kernel extensions has now been updated to use system extensions or another modern replacement, so updating old software could solve the problem.

Tools for working with kernel extensions are detailed in the article on boot loops. If you need to remove a kernel extension, this article explains how to do that. One quick way to disable all third-party kernel extensions on an Apple silicon Mac is to start it up in Recovery, go through to the main Recovery window, open Startup Security Utility from the Utilities menu, disable loading kernel extensions and return it to Full Security.

Modern System Extensions don’t run with the same level of privilege as kernel extensions, so in theory shouldn’t be capable of causing kernel panics. However, experience has shown that the macOS kernel extensions required to support them can prove unstable and cause panics. This should be apparent from careful reading of the panic log.

Reading the panic log

Unlike app crash logs, panic logs are normally relatively brief and to the point. Although they may be non-specific and not help you much, in many cases they contain obvious clues as to what caused the panic. Formats have changed over the years, but the following sections are likely to prove worthwhile examining.

Immediate cause

At the very top, following the first word panic, the log may suggest a cause. This is most common when a memory leak is to blame, such as
panic(cpu 8 caller 0xffffff80017729eb): "zalloc: zone map exhausted while allocating from zone kalloc.12288, likely due to memory leak in zone kalloc.48 (6586956000 total bytes, 137228148 elements allocated)"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.141.1/osfmk/kern/zalloc.c:3627

This first tells you which CPU core the panic occurred on. If you have repeated panics, keep a note of these, as they may cast suspicion on a core with a hardware problem.

In other cases, you may not be as lucky, and the cause is just given as an ‘exception’, or
panic(cpu 0 caller 0xfffffe002f4e48bc): cannot find IOAESAccelerator
panic(cpu 0 caller 0xfffffe001abd5e94): Kernel data abort
so you’ll need to look for other clues. As the name implies, exceptions are conditions requiring special handling by the operating system. They include page faults, in which something has tried to access an invalid memory address, invalid instruction codes for the processor, and general protection faults which include a wide variety of other bugs. As far as the user is concerned, all exceptions indicate a bug or problem in the code that’s being run.

OS details

You may see a line like
OS version: Not set yet
simply indicating that the version hasn’t been recorded yet. When it has, this gives its build number rather than version. Most importantly, you should see a statement of the kernel version running:
Kernel version: Darwin Kernel Version 24.2.0: Fri Dec 6 18:57:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_VMAPPLE
You can check that against that shown in Software in System Information.

On Apple silicon Macs, you should also see the iBoot version, and the current level of boot security:
iBoot version: iBoot-11881.61.3
secure boot?: YES
The latter is important, as running in Secure Boot means that no third-party kernel extensions have been loaded.

Memory leak

If there has been a memory leak, the panic log may well contain a breakdown of system memory zones giving more detailed clues.
Zone Name Cur Size Free Size
vm objects 78041088 26795008
…
Zone Name Cur Size Free Size
kalloc.32 280834048 3040
kalloc.48 6586956000 4896
kalloc.64 4241453056 5000896
…
Note how the Free Sizes of kalloc.32 and kalloc.48 are very small, and that of kalloc.64 is fairly low too. This is consistent with the kernel running out of memory in one of those zones. Further information may follow:
Backtrace suspected of leaking: (outstanding bytes: 288)
Because there’s the suspicion of memory leakage, the panic log also gives a detailed backtrace of where it suspects that leakage is occurring, and details of the kexts involved in that. Note that those may not coincide with any kexts identified earlier as possible culprits.

Panicked task

This may simply be the kernel
Panicked task 0xfffffe166cff1f18: 10735 pages, 374 threads: pid 0: kernel_task
or may give more specific information
BSD process name corresponding to current thread: WindowServer
Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev
or
Panicked task 0xfffffe1b55369798: 24964 pages, 8 threads: pid 800: com.apple.Mobile
This is the name of the process running its code at the time, and can be another clue as to where the problem lies.

You may also be given a list of kernel extensions that might be involved:
Kernel Extensions in backtrace:
com.apple.filesystems.apfs(1412.141.1)[6DA33D13-4501-3D48-B4D8-0329E6AEC86D]@0xffffff7f84e7d000->0xffffff7f84fa4fff
dependency: com.apple.kec.corecrypto(1.0)[804DD660-F561-3444-A076-05D7A52D65E3]@0xffffff7f82746000
…

Third-party kexts

Whatever the cause, you should next look at the list of unloaded and loaded kexts forming the rest of the panic log. These are listed in the order that they were loaded, with the most recent kext at the top. As third-party kexts are the last to be loaded, the top of the lists start with any third-party kexts installed on that system and loaded at the time of the panic.
last loaded kext at 939128480512562: >!UAudio 323.4 (addr 0xffffff7f86baa000, size 434176)
last unloaded kext at 948795488738566: >usb.IOUSBHostHIDDevice 1.2 (addr 0xffffff7f8556c000, size 45056)
loaded kexts:
>!ATopCaseHIDEventDriver 3430.1
…
In most cases, the name of the kext as you’ll find it in /System/Library/Extensions is the last part of the ID given. For example, the kext with the ID of com.apple.driver.AppleMobileFileIntegrity is named AppleMobileFileIntegrity.kext.

If those lists contain any third-party kexts, they should be immediately suspected as being the cause of that panic, unless another cause is apparent.

Summary

• Save the panic log before sending it to Apple.
• Consider running Diagnostics if there’s the possibility of a hardware problem.
• Consider disconnecting a peripheral if that could be the cause.
• Consider removing/updating any third-party kernel extensions, or better, disabling them altogether.
• Read the panic log to provisionally identify its most likely cause, and try to address that.
• Report the panic to Apple Support and/or via Feedback.
• Keep a careful watch for any further panics, and be prepared to revise your provisional diagnosis.