A few months ago, I setup a Gmail and iCloud account for an agent I’ve been using. At some point, I think I copied/cloned a temporary VM that was signed into iCloud and this ultimately resulted in non-dissmissable error being displayed on my current agent’s Mac VM in System Settings:

The symptoms were:

• The password/keychain sync could not be enabled
• At times, attempting to sign into the App Store would fail and return “Unknown Error”
• A permanent red “1” badge over the “System Settings” icon (unacceptable for inbox-zero personalities)

This annoyed me quite a bit, and I tried every possible workaround to fix it, but it would just prompt me for my local password, spin for a second, and ultimately do nothing. Codex decided it would be reasonable to open up a live chat support case with Apple in the background, which I didn’t notice until I heard the messaging noises and saw that it had already braindumped every detail on the Apple customer service rep:

You haven’t lived until you’ve watched an AI harness interact with a live customer service rep. Turns out, humans aren’t the only ones to demand a manager:

I ended up having two live support sessions with Apple techs; I was mostly curious - I didn’t realize they had the ability to request viewing permissions on machines via iCloud. These calls were mostly just information gathering sessions and were generally useless. I would summarize it as “jump through 500 hoops so I have justification to escalate this ticket” and I eventually decided my time would be better spent just creating a new email/iCloud account.

I had been working with Astra to diagnose the issue and try workarounds, but none of the normal troubleshooting steps worked. At some point, I saw it interacting with otctl, a “Command line interface do provide diagnostic information for iCloud Keychain syncing”. Eventually, it referenced a specific build of otctl from a build of MacOS Ventura that had a resetProtectedData command and resetoctagon path included, but they were marked “internal-only”. I tasked Astra with grabbing a copy and attempting to patch around the internal-use only code in the binary, but it quickly became clear this was a deadend due to code signature enforcement.

Instead, I asked it to reverse the binary and to build our own tool that included the same functionality provided by the resetProtectedData command. It wasn’t able to interact with any local services due to entitelemt requirements, which meant that we had to rely purely on calls to the cloud service. In addition, Astra had to work out the correct request format, authentication headers, CloudKit routing, and response encoding expected by iCloud.

The reset was one authenticated HTTPS POST to Apple’s CloudKit gateway, invoking the private Cuttlefish/reset function.

POST https://gateway.icloud.com/ckcoderouter/api/client/code/invoke

x-cloudkit-functionroutinghint: Cuttlefish/reset
x-cloudkit-containerid: com.apple.security.keychain
x-cloudkit-bundleid: com.apple.security.cuttlefish
x-cloudkit-databasescope: Private
x-cloudkit-environment: Production
x-cloudkit-authtoken: <existing account CloudKit token>
x-cloudkit-userid: <account's container-scoped user ID>
Content-Encoding: gzip
Content-Type: application/x-protobuf;
</snip>

The inner reset payload was just six bytes:

08 01 2a 02 08 10

Decoded as Protocol Buffers:

Once the reset request was issued, this cleared the cloud trust state. This time, following the System Preferences “Resume Data Sync” flow progressed to an additional device-password prompt that the earlier attempts had failed to reach. I typed in the credentials from the other machine, and it resolved the issue.

Another win for AI-assisted DIY fixes.