Recent items menus have stopped working on my iMac

For me, this partially fixed things:

1. Close all open apps.
2. Move ~/Library/Preferences/com.apple.recentitems.plist (and ~/Library/Preferences/com.apple.recentitems.plist.lockfile if it exists) to a backup directory.
3. Reboot.

In my case this fixed the recent items lists under the File menu in each app and the Apple menu. But the context menus on Dock icons still do not update.

I ran into this today on a month-old iMac. The only thing that isn't fresh about it is my account, which has been replicated across 5 machines and 12 major MacOS versions using Migration Assistant when possible, leaving it with a fair bit of cruft in ~/Library/Preferences/. Unfortunately, in recent versions Apple has made it complicated to clean up that directory effectively by trashing files because cfprefsd manages the real preference info and you need to talk nicely to it with the defaults utility.

Anyway, I fond that every time I tried to change the preference I got a sequence of log entries like this:

Jul 14 18:14:03 extravagant sharedfilelistd[411] <Critical>: [default] [<CFString 0x7fff77ea0e00 [0x7fff77f58440]>{contents = "com.apple.LSSharedFileList.RecentApplications"}] List write failed invalid info items: (null) properties: (null)
Jul 14 18:14:03 extravagant sharedfilelistd[411] <Error>: -[ListStore writeListItems:properties:withListIdentifier:notificationHander:] [com.apple.LSSharedFileList.RecentApplications] List write failed invalid info items: (null) properties: (null)
Jul 14 18:14:05 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: Error getting number of recent items of type 2, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: New number of recents: 30
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: Error getting number of recent items of type 1, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: Error getting number of recent items of type 2, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: Error getting number of recent items of type 3, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:13 extravagant com.apple.xpc.launchd[1] (com.apple.preference.general.remoteservice[85562]) <Notice>: Service exited due to signal: Killed: 9

Also, both defaults domains and a few dozen files in Preferences told me that most applications with a proper defaults domain like com.example.appname also had a defaults domain like com.example.appname.LSSharedFileList which contained lists of recently used files. Except they weren't recently used files at all. None of the *.LSSharedFileList.plist files had changed since my migration from my old Yosemite machine, and neither had com.apple.recentitems.plist. So I cleaned house by running these commands inside ~/Library/Preferences/:

defaults delete com.apple.recentitems
rm com.apple.recentitems.plist*

The defaults command tells cfprefsd to remove all of the settings in that domain, which leaves a 42-byte logically empty .plist file and a 0-byte .plist.lockfile file which the rm command removes.

defaults find LSSharedFileList |grep 'keys in domain .*LSShared'|cut -d"'" -f2 |xargs -L1 defaults delete
rm  *LSSharedFileList.plist*

Less obvious, but essentially the same thing for all defaults domains with LSSharedFileList in their names

find . -name "*.plist" -print0 |xargs -0 -L1 plutil -lint |grep -v ': OK$'|cut -d: -f1|sed 's/.*/"&"/' |xargs rm

Even less obvious, but apparently crucial. This pipeline finds all of the *.plist files in the current directory (which was ~/Library/Preferences/,) checks each one for validity with plutil -lint, parses out the filenames of those that are not "OK", enquotes them to protect from embedded spaces and the like, and removes them all. In my case the invalid *.plist files were all 0-byte antique files for stuff that can't run on El Cap anyway, so I was sure I was not deleting any actual information. YMMV!!

find . -size 42c -name "*plist" -delete

This swept out any *.plist files that were 42-bytes long, the size of a logically empty plist in binary format. I had a few of those hanging around and they might have been causing the complaint from sharedfilelistd.

killall sharedfilelistd

That terminated the instance of sharedfilelistd running under my account. The system restarted a fresh instance automatically. I'm not sure this was needed, but it seemed prudent since I had just wiped out a bunch of information from the preferences subsystem that was related to the old way of doing what sharedfilelistd apparently does in El Cap.

NOTE: Those 7 commands are the abridged version of what I did that made sense and had effects, scattered across 3 hours of poking around and testing and trying to find info on sharedfilelistd to no avail.

It is also worth noting that there's no sudo involved here, because I was in my own ~/Library/Preferences/, manipulating my own preferences realm. The Recent Items menu and hence its settings are user-specific so wherever that setting is stored (never worked that out...) has to be user-specific as well, not something requiring root to fix. There's a prior response that includes an unexplained massive permission/ACL/flag wipe, run with sudo, that didn't even work for the author, and may cause serious systemic harm. This is nothing like that. Also note that it does not require logging out, rebooting, booting in Recovery Mode, or doing anything else likely to be disruptive.