Apple’s warning about AI agents misusing Full Disk Access sparks a debate over Mac security, privacy, and the potential consequences for developers and users. The MacVoices Live! panel examines Apple’s permission system, the need for more granular controls, and concerns about restricting legitimate applications and developer options. The discussion also questions Mark Zuckerberg’s involvement in drafting the White House’s voluntary AI regulatory accord and whether self-regulation is the best solution to potentially dangerous advances in AI. 

💾

Apple (Hacker News, MacRumors, Lobsters, TidBITS Talk):

Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac. Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users’ full knowledge and understanding.

[…]

Going forward, we will introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action. Addressing this is critical. As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially.

Guy English:

It was pretty obvious something like this would happen after the Muse accessing Messages news.

Jeff Johnson:

What we have is just one noisy, confused journalist, Jason Aten. He granted FDA to Muse but refuses to admit it, to the public or even to himself.

I see several issues with the current Full Disk Access system:

1. Backup apps need FDA, but so do many other types of apps. Often, they don’t need full disk access but rather they need to work around a missing or broken API. All of my apps except ToothFairy use FDA, not because I want to or because it’s easier to code, but because without it the user experience would be much worse or key features wouldn’t work at all.

2. There is no API for apps to see whether they have FDA or to request it from the user. It’s not like, say, accessing the user’s Contacts where macOS pops up a standard dialog and the app supplies a “reason” string to specify why it wants access. Instead, each app presents its own set of instructions for how to enable it deep in System Settings. It requires the confusing maneuver of first adding the app to the list; it doesn’t automatically show up with a slider switch next to it, like with other privacy settings. This adds an obstacle for users to get up and running with an app but doesn’t really provide additional security, just obscurity.

3. FDA is not granular. There’s no way for apps to request only the permissions they actually need. For example, SpamSieve wants to be able to access the user’s mail, but it doesn’t need or want to see their iMessages or browser history. This is bad for users because they may be exposing more information than they want to and bad for developers because some users will think your app isn’t worth the risks.

4. There is no way for the user to see what the app actually did. If it tells me that it wants FDA to access my mail but actually it mucked around with my Time Machine backup, how would I know?

5. Apple’s wording in System Settings is not very clear. I don’t think most users really understand what FDA is doing.

6. The previous items combine to create opportunities for malfeasance. It’s normalized that many apps that seem like they wouldn’t need full disk access do need FDA, so this makes it easier for apps to trick the user into granting it under false pretenses. Apple requires that apps coach the user through the process, so it’s normal that users mostly see text from the app (which might not be trustworthy) rather than standard text from Apple, as with other permissions prompts.

But the problem in the Muse case was not malfeasance. Rather, it seems that Muse asked Aten to enable FDA, but he doesn’t remember doing so or didn’t understand what he was doing. It sounds like Apple wants to make this consent more clear, which is good, but other issues would remain. As with the recent keychain story, this feels like a bandaid rather than a thoughtful solution to the real problem. The issues with FDA were clear when it was introduced 8 years ago, and many Radars were filed, but it’s been virtually unchanged since.

Apple seems to think that by making a scarier warning they can convince more users not to grant FDA—or at least perhaps deflect blame from Apple to the user if they later regret it. Maybe that solves Apple’s problem, but it doesn’t really solve the user’s problem. The user is installing Muse because it’s more capable than Siri. They probably do want it to access some protected data, e.g. so it can find information in their mail or messages. So they actually do need to give it FDA. Aside from deterrence, Apple is not actually protecting the user. And the deterrence is kind of sketchy. Rather than providing a safe way for users to choose what to share with a competing product, Apple is saying the only option is to share everything, and then discouraging that. Meanwhile, there’s no switch to turn off Apple Intelligence. It’s like they expect you to stay on eWorld and not download Netscape. I actually really liked eWorld, and the broad Internet wasn’t totally safe (though neither was eWorld), but that doesn’t seem like much of a strategy.

Jeff Johnson:

Below I’ve embedded […] a screen recording of a macOS Virtual Machine showing the first run experience of the Meta Muse app.

[…]

It’s important to note that macOS has no API for an app to request or acquire Full Disk Access. The only way for an app to receive Full Disk Access is via the Full Disk Access pane of System Settings, as shown in the video. Thus, the only thing an app can do is open the System Settings pane for the user, as also shown in the video. Once the user is in System Settings, it’s up to the user to manually grant Full Disk Access.

Without Full Disk Access, Muse cannot access the user’s Messages database. If it could, that would be a macOS zero day vulnerability.

[…]

Aten oddly writes as if the “if you give it Full Disk Access” earlier in the article were counterfactual, merely hypothetical, still insisting that he did not give Full Disk Access to Muse.

John Gruber (Mastodon):

I really worry about just how much Apple is going to lock Full Disk Access down. I use it with several apps that couldn’t function properly without it, and would be severely hampered if I needed to authorize it manually every time they do something.

Ben Lovejoy:

However, what Apple absolutely must not do is to make the mistake it made with macOS Sequoia over screen recording. Sure, this is also incredibly dangerous and very strong warnings are appropriate, but what Apple did then was to force us all to confirm these permissions on a weekly basis, as well as after every restart.

Dave Nanian:

Well, this is certainly ominous news for backup programs.

Like it’s not hard enough to turn this stuff on…

Nick Heer:

Is Apple suggesting this capability could be limited in the future to backup applications alone? I do not like that.

[…]

Because of the lack of information available at present, I do not want to get too far ahead of myself, but I am concerned that it could be a significant curtailing of application permissions. It has the potential for further self-preferencing, as Apple will surely exempt Siri from the kinds of permissions requests it requires of third-party apps, even as it is updated with additional capabilities.

[…]

Call me a naïve little baby if you want, but I do not think preserving Siri’s dominance on Apple’s devices is the company’s reason for locking down Full Disk Access. But Apple’s existing restrictions are part of the reason Siri was awful for a decade. If it had the opportunity to compete with third-party replacements, I doubt it would have languished in a miserable state for as long as it did.

John Voorhees:

[Only] a handful of apps to which I’ve granted Full Disk Access are backup apps. Others include the Finder replacement Bloom, launchers like Alfred, the wonderful selection utility PopClip, Apple’s own Pixelmator Pro, Setapp, TestFlight, Supercharge, Madden NFL 27 Arcade Edition, Hazel, and many others. It’s a diverse selection of apps covering everything from Apple’s own apps to Mac utilities that are longtime favorites of MacStories readers, and even one Apple Arcade game.

[…]

On the one hand, it seems to suggest that users will simply have to jump through additional explicit hoops to grant Full Disk Access to their agents and other apps. On the other hand, claiming that Full Disk Access was designed solely for backup apps raises red flags that could signal that the company intends to restrict the kinds of apps that can use Full Disk Access. I sure hope not.

Dan Moren:

But there are plenty of legit uses for Full Disk Access. Just looking at my MacBook Air this morning, I’ve given that permission to three apps: Terminal, BBEdit, and SuperDuper. All apps that I trust with that level of power because of their long history and because in order to do what they do best (or at all), they need that access. (Interestingly, on my Mac mini, that list also includes SpamSieve, KnockKnock, and Shortcuts—though not BBEdit, for whatever reason.)

[…]

I think there is a good argument for protecting Full Disk Access further, but there’s also only so much you can do to protect a user from themselves. Ultimately, this is a cat-and-mouse game, and while I don’t want my data purloined or misused, I also don’t want my computer locked down to the point that I can’t use it for all the things I want to do.

Ben Thompson (Hacker News):

To say that I’m nervous about what Apple’s solution will entail is a massive understatement. There is one aspect in which the Mac is the perfect agent host: Apple has, for decades, invested in a combination of scriptability, automation, and accessibility APIs (these are very often the same thing) that makes it remarkably well-suited to computer use. Then there is the fact that macOS is a certified Unix system; this means that agents — which are perfectly suited to the command line — have access to the entire universe of tooling built for Unix systems. And, of course, Mac hardware is amazing.

The problem is that for my particular use case — a headless, always-on Mac Mini that I primarily access from other computers and my phone through the ChatGPT and Claude apps — macOS is incredibly hostile. The biggest issue is GUI-only permission prompts that are invisible to software running on said computer, including agents.

[…]

This system is annoying but manageable on your primary Mac; it’s a disaster on a headless Mac running agents, for two reasons. First, agents write new programs all of the time, and in my case, those programs need access to devices on my network (SMB shares, for example, trigger a TCC warning). What I need is a permission layer for agents, not the programs they create; TCC is operating at the wrong level of abstraction.

Second, the TCC subsystem exposes its prompt in a protected space that no program can see; that means that programs silently fail and the agents don’t know why; what I have to do is remember that there is probably a permissions prompt on screen, log into the Mac Mini with screen-sharing software, and click OK.

Wade Tregaskis:

Apple’d get a long way by just renaming the privilege. How many laypeople understand what a “disk” even is? Regular people just talk vaguely about how much “memory” their computer has - if they think about it at all other than when they run out of disk space - at which point, how many just think that means they have to buy a new computer? So, how about just “Full Access to All Your Data”? Call it what it basically is.

Jason Anthony Guy:

If Apple has time (or is especially motivated), it might also add more granular options to control what data apps can access. For example, instead of today’s single toggle that grants an app access to the broadly defined “data like Mail, Messages, Safari, Home, Time Machine backups, and certain administrative settings,” it might instead allow you to enable access to specific data on a per-app basis. This would allow, for example, Muse to access Mail and Safari, but not Messages or Time Machine.

Kevin Grant:

With all the levels of entitlements and crap they added, I find it ironic that SIP is “only” implemented as “open up every damned thing to everyone” without more refined levels.

John:

I was frankly surprised when I learned FDA was for a machine, across user accounts, rather than for a single user. It seems like granting root, something the *nix community has tried to reduce and lock down for decades.

I certainly don’t trust anyone’s AI with root, and creating a weak, non-admin, user for AI experiments should be a safe path.

Jimmy Callin:

While [Gruber sees] this as a “why we can’t have nice things” moment, I see it as another case of Apple using privacy to limit competition in areas it currently lag behind.

I’d prefer to decouple trust in how my personal data is handled from trust in a particular platform or software vendor. That’s what I personally value about EU’s approach: give people rights over their information, make mishandling it a legal liability, and severely punish companies that break those rules.

Apple getting unique privileges to access sensitive data simply because they own the platform, and thus there is an implicit trust in their handling of it, feels like a brittle long-term strategy. If this works without causing anti-trust issues, it only makes Apple more dominant while locking out potentially useful software.

Previously:

• I Said No and Apple Said Yes
• Locked Down Passkey and Keychain Backups
• Meta AI for Mac and Muse
• Mandatory Apple Intelligence
• Reporting a Full Disk Access Bug to Apple
• Terminal and Full Disk Access
• macOS 11.4 Breaks Full Disk Access for Helper Tools
• The Alert Hammer
• Mojave’s New Security and Privacy Protections Face Usability Challenges

Update (2026-10-06): See also: TidBITS Talk and Vitor.

Howard Oakley:

Whether or not you would ever want to unleash AI agents on your Mac, Apple does need to refine Full Disk Access as a matter of urgency. But its design and engineering cannot be rushed. Merely adding to the complexity of current Privacy settings wouldn’t help users, many of whom already find privacy protection confusing and opaque.

Sherief, FYI:

it’s clear there’s consumer demand for automated access to iMessages, and instead of offering a proper API with audit trails and fine-grained controls Apple would rather force users to FDA then cry fowl when they grant FDA.

Previously:

• The Difficulty of Accessing Old iMessages
• Search in Messages.app

Update (2026-10-14): Adam Engst:

63% of the more than 200 people who voted said they had granted Full Disk Access to 6 or more apps, with over half of those people saying they had given 11 or more apps that level of access. In short, Full Disk Access is essential to how many of us use our Macs.

At the same time, Full Disk Access feels a bit like a Band-Aid, partly because Apple hasn’t put enough thought into more granular permissions, forcing many apps to rely on Full Disk Access even when they don’t need all its capabilities.

[…]

Given that Apple’s statement about Full Disk Access seems to have been prompted by the release of Meta’s Muse AI agent, I would suggest Apple think more carefully about how such agents should be handled. They may legitimately need Full Disk Access, along with numerous other permissions, but beyond what would appear in an App Privacy Report, I would like to see them maintain complete logs of every permission-enabled action they take on your computer. Preferably in human-readable form.

The panel looks at macOS 27 ending Time Capsule backup support, then debates Google’s new Android-based laptops and its attempt to build a tighter ecosystem. Other topics include Chrome’s retro-style bookmark launchpad and GM’s geolocation privacy settlement before a deep dive into cloud storage, AWS data loss, redundancy, service agreements, and why cloud storage is […]

💾

I remain unhappy with Apple’s passkey backup story. There’s little documentation about this, but from what I can tell:

• There are no automatic versioned backups. (Syncing is not backup because it doesn’t protect you against human error, bugs, or attacks.)

• Even if you have a Time Machine backup, it’s not possible to restore it to the same Mac without logging into iCloud. This could be a problem if your account is locked or compromised.

• Restoring it to a different Mac is impossible because the decryption key is stored in the other Mac’s Secure Enclave. Apple is protecting you from accessing your own backup, even though the keychain is already an encrypted file, protected by the password that you set. (And the Time Machine or clone drive that it’s stored on is probably encrypted, too.)

• The Passwords app can now export passkeys, but you cannot create an export file that you can import back into Passwords on another Mac. You can only export to a third-party password manager that’s installed on the same Mac (which may require a working Apple account). Even then, this does not include passkeys for Apple services; they don’t show up in the Passwords app. There are also some other restrictions around shared items and Sign In with Apple.

The above is last year’s news, but I don’t think I had written it all in one place before. The new bad news is that, as of macOS 26.4, these problems now affect regular passwords, not just passkeys. (You do have more flexibility to export passwords, though.)

Rich Trouton (Hacker News):

Historically, you could copy the login keychain file from one Mac to another and be able to open it on the destination Mac by providing the password to that keychain. As of macOS Tahoe, this does not appear to work for Macs which use Secure Enclave.

[…]

From that, it appears that unlocking the login keychain requires more than the password because the keys it unlocks are tied to the Secure Enclave of the Mac where the keychain was created. With the decryption keys stored in the source Mac’s Secure Enclave, manually copying the keychain to another Mac and then unlocking it won’t work. The password you have for the keychain may be correct, but the actual keys needed to decrypt its contents won’t be available on the destination Mac.

Jeff Johnson:

According to Apple, all Apple silicon Macs, as well as some Intel Mac models, have the secure enclave processor, so the issue affects millions of Mac users.

[…]

If anything happens to your Mac, if it’s stolen or becomes inoperable, your login keychain is also lost, unrecoverable, even if you have a copy of the login keychain file! This is a stunning development that has left me bewildered and irate. WTF was Apple thinking? To my knowledge, Apple did not even publicize the change in Tahoe.

[…]

How does Migration Assistant handle the situation on Tahoe? I don’t know. I would guess that since Migration Assistant still has access to the old Mac, it simply decrypts the old login keychain and copies the login keychain entries to the new login keychain on the new Mac, rather than transferring the keychain files directly.

[…]

I recommend that you open your login keychain with the Keychain Access app (now located in /System/Library/CoreServices/Applications) and check what’s in there, the data that you’re in danger of losing. Whether you realize or it not, many apps use the login keychain. For example, Google Chrome and other Chromium browsers store passwords in the login keychain. MailMate stores email account passwords in the login keychain. The open source RSS reader Vienna stores website passwords in the login keychain. The Zoom app also uses the login keychain. My Developer ID code signing certificate is stored in the login keychain; if I’m not mistaken, I believe that Apple’s own Xcode put it there. And of course, any items that you’ve manually added to the login keychain would be lost if the keychain file could not be unlocked.

Howard Oakley:

I have confirmed that a login.keychain-db copied from my Mac mini M4 Pro to a virtual machine (VM) running macOS Tahoe 26.6.2 cannot reveal any of its secrets to the Keychain Access app on the VM, as it refuses to accept the valid password. Not only that, but Keychain Access running in a VM cannot access the login.keychain-db keychain copied from another Tahoe VM, although neither has been anywhere near a Secure Enclave.

If you intend migrating manually between Macs, don’t waste time trying to copy across the login keychain, as it’s not likely to work, and its secrets will remain.

[…]

I performed test migrations between VMs, and demonstrated that Migration Assistant does copy the contents of the login keychain successfully to the destination Mac.

I think this only happens if you migrate over a network, with the old Mac acting as a server. I prefer to connect the old Mac using Target Disk Mode, but in that case Migration Assistant wouldn’t be running on the old Mac so the special sauce wouldn’t work. Likewise if I were trying to do the migration using a third-party cloning app.

Howard Oakley:

• Loss of physical access to a Mac running 26.4 or later prevents access to any items stored in its login keychain.
• Hardware failure requiring logic board replacement may have the same effect on restoring the contents of its login keychain (assuming that migration from a backup doesn’t work).
• Restoring an Apple silicon Mac in DFU mode may be similar in effect.

What I don’t know yet is whether you can unlock and access any login keychain written by macOS 26.4 or later and migrated from a backup accessed directly from a different Mac. This would occur in one-Mac migration, when Migration Assistant uses a backup of a Mac not acting as a Migration server. This would only be possible if the backup also stored the additional secret required to access the login keychain, which seems unlikely.

[…]

Apple’s documentation for macOS Tahoe and the copying of keychains makes no mention of this change, in spite of its serious consequences and the change being made almost six months ago.

It there states “If you didn’t use Setup Assistant, the best way to copy your keychains to a new computer is to export and then import them using Keychain Access”. However, Keychain Access can only export some keychain items including certificates and keys, but not passwords. And to do that, the Mac must be able to unlock and access those items in the source keychain. Thus, Apple’s recommendations are out of date and will now fail.

rsUSA0 (via Jeff Johnson):

When upgrading to macos 27 Golden Gate, I erased my system through recovery to do a clean install. I planned to manually migrate data back to the computer from an external drive clone of Macintosh HD and a Time Machine backup. This has worked well in the past and eliminated system bloat.

When I manually migrated my login keychain, it opened, showed entries, but it wouldn’t accept my password to reveal any actual passwords. The window shakes like I’m using the wrong password. I’m 100% sure I’m using the correct password. I also tried every password I’ve ever used and I’m certain it’s not a password issue.

Perhaps even restoring to the same Mac failed because the clean install wiped the key stored in the Secure Enclave. [Update (2026-10-01): See update below.]

Jeff Johnson:

Some people who read my previous blog post misunderstood the issue, because they didn’t know that the macOS login keychain is distinct from iCloud Keychain.

[…]

In the Keychain Access app, you can see two separate default keychains, one of which is the login keychain. The other default keychain is named “iCloud” if you’ve enabled iCloud Keychain, “Local Items” if not. There’s actually a longstanding issue with this keychain analogous to the newer issue with the login keychain.

[…]

Mac users like myself who forsake iCloud Keychain face the prospect of no disaster recovery for the Local Items keychain. My habit is to manually create a new password item in the login keychain and only then supply the credentials to an app, for example, Safari AutoFill. Ironically, the login keychain change brought by macOS 26.4 sabotages my password backup procedure[…]

jen1x:

Today, I got my new Mac mini M6. When I started setting up the new machine, it asked me to update to macOS 27, so I followed the instructions.

[…]

After signing in to iCloud, it asked me to enter the passcode of one of my Apple devices. I entered the correct passcode and even tried the passcodes for all of my devices, but I keep getting the same message:

Verification Failed
There was an error verifying the passcode of your iPhone

I don’t like having to rely on iCloud.

Previously:

• SuperDuper’s “Follow-Up”
• macOS 26.4
• 2025 Six Colors Apple Report Card
• Locked Out of Apple Account Due to Gift Card
• Downloading Xcode With a Passkey
• iOS and iCloud Keychain Are Hostile to Backups
• Passkeys Credential Exchange
• Passkeys: A Loss of User Control?
• Fixing iCloud Keychains, and Backing Them Up

Update (2026-10-01): TN3137 has been updated for macOS 26.4:

Historically each file-based keychain was a standalone file. You could, for example, copy a keychain file from one Mac to another and still use it, as long as you knew the keychain password.

In macOS 26.4 and later that’s no longer the case. A keychain file might reference a protected entropy file. To unlock such a keychain you need both the keychain password and the protected entropy file.

[…]

These protected entropy files are stored in /var/db/SystemKeys. If you’re creating a backup product, make sure to back up that directory. Without it, the keychain files that you back up might be useless.

[…]

The /var/db/SystemKeys directory is not directly accessible, even when running as root, so you can’t copy a protected entropy file in the normal way. To access it, disable System Integrity Protection (SIP).

First things first: I don’t think turning off SIP every time you make a backup is a real solution. And I don’t understand what problem Apple is really trying to solve with protecting the entropy file; it seems like they don’t trust their own encryption. Lastly, it’s not explicitly stated, but I don’t think copying the entropy file helps with backing up passkeys.

That aside, I find the details both illuminating and confusing. This probably explains the rsUSA0 case above, where restoring to the same Mac didn’t work. The key wasn’t stored in the Secure Enclave but rather in the entropy file on the SSD, which had been wiped. This also suggests a simpler way for Migration Assistant to work; it could have special access to copy the entropy file without having to actually open the keychain.

It also seems to be saying that, if you turn off SIP and copy the entropy file, you can then access your keychain backup from another Mac. But I’m not sure how to square that with Apple’s keychain documentation:

Keychain items are encrypted using two different AES-256-GCM keys: a table key (metadata) and a per-row key (secret key). Keychain metadata (all attributes other than kSecValue) is encrypted with the metadata key to speed searches, and the secret value (kSecValueData) is encrypted with the secret key. The metadata key is protected by the Secure Enclave but is cached in the Application Processor to allow fast queries of the keychain. The secret key always requires a round trip through the Secure Enclave.

How can copying the entropy file work if the Secure Enclave is required? My guess is that the entropy file itself is encrypted (NSFileProtection) using the Secure Enclave. So accessing it on the original Mac does require going through the Secure Enclave. But when you make a backup, the entropy file gets decrypted. Maybe accessing the keychain on the second Mac causes file protection to be re-applied to the contents of /var/db/SystemKeys, so then it becomes protected by that Mac’s Secure Enclave.

Previously:

• Accessing the Keychain Without the Password

Update (2026-10-02): Dave Nanian (Mastodon):

This is obviously not a good user solution, because no one is going to boot to Recovery, turn off SIP, back up, boot back to Recovery, and turn SIP back on. Thinking they would do so is kind of crazy.

[…]

SuperDuper handles this situation. When you make a bootable copy, the required keys are copied without requiring any special steps.

SuperDuper itself can’t read the entropy file, but it uses Apple’s asr tool to make bootable backups, and that has special access. (Unfortunately, it can’t update the entropy file without making a fresh bootable backup, but in practice I don’t expect it to need updating.) I had not been bothering to make most of my backups bootable, since in most cases I just want to restore to an internal SSD, not actually boot from the backup. But I now think it makes sense to choose bootable backups as the default.

Howard Oakley (Rich Trouton):

I won’t expand on my feelings any further than by saying that in my 37 years as an Apple developer, I have never come across anything so shameful.

Unfortunately, it seems like the keychain stuff was just the warm-up act.

Update (2026-10-05): Howard Oakley:

[macOS 26.4] Added the protected directory at /var/db/SystemKeys to backups of Data volumes, and protects them in backups.

So Time Machine does back up the entropy file. I missed this because I didn’t see /var/db in my backups, but it turns out that they do have /private/var/db/SystemKeys and are just missing the /var symlink.

Update (2026-10-07): Jeff Johnson:

The -s option to the security show-keychain-info is not yet documented in man security, not even on the latest version of macOS Golden Gate. Moreover, the -s option does not work on macOS Sequoia and earlier. In general, the security show-keychain-info command reveals no information unless the specified keychain is unlocked, which makes it impossible to discover the salt of a keychain file that you can’t currently unlock. However, as long as you already have the entire contents of the /var/db/SystemKeys directory from the macOS volume on which a keychain file was created, the inability to determine the keychain file’s salt beforehand shouldn’t be much of a problem, because in practice there are typically only a few salt files, so you can simply copy them all to another macOS volume.

[…]

You don’t actually have to disable SIP to add files to the /var/db/SystemKeys directory, because you can do so from another boot volume. You have to boot into recovery anyway in order to disable SIP, so you could simply edit /var/db/SystemKeys from recovery rather than disabling SIP on the non-recovery volume.

The security unlock-keychain command lacks an option to specify the location of an entropy file or to provide the file data directly, so unfortunately a login keychain can’t be unlocked from the recovery volume, only from a volume where you can add files to the /var/db/SystemKeys directory.

Mike Bombich:

I remember seeing this one way back in Big Sur; you’d create a perfectly functional bootable copy of the system, but it wouldn’t show up in the Startup Disk Preference Pane. Apple ultimately resolved that issue in macOS Monterey, but now we’re seeing it again — unfixed in the Golden Gate release candidate.

The new CCC has a workaround, as does SuperDuper.

CCC 7.2 introduces a hybrid approach for bootable backups: as long as the source and backup OS versions are the same, CCC will update the backup incrementally without requiring any task configuration changes. This new approach will make many of the CCC-specific features available for bootable backup tasks, e.g. backup versioning, Quick Update, insight into what changes were made to the source between events. For the long stretches of time where your Mac’s OS isn’t getting updated every day, now you can enjoy the full benefits of the CCC backup solution.

These are great benefits for anyone that requires a bootable backup, but this isn’t a panacea. If the OS versions don’t match, the destination (and all backup versions) still must be erased and recloned; again, to offer the most reliably-bootable copy of macOS. We made improvements here, too. By default, CCC will ask for your approval before erasing the destination — this allows you to schedule your backup task without the fear of the backup getting automatically erased whenever the source OS is updated. That also allows you to retain the option of downgrading the source volume’s macOS, which you might want a day or so to assess.

Previously:

• macOS 27 Golden Gate
• SuperDuper 4
• Carbon Copy Cloner 7.1.3