Finder Recents Is Empty on a Mac: What That List Is Actually Asking For

You clicked Recents in the Finder sidebar and got an empty window — or a list that stops a fortnight ago, with none of today’s work in it, while the files sit in Downloads exactly where you left them.

Every thread you have found says to relaunch Finder and rebuild the Spotlight index. Sometimes that is the answer. More often Recents is working exactly as designed, and the design is narrower than anyone tells you.

FileBo sidesteps that design: its panel lists a file from the moment it arrives, opened or not, folders included. The page below is Finder itself — what Recents actually asks, and the faults that really do empty it.

Recents is not a folder

Recents sits in the sidebar looking like a folder, but there is no folder behind it — no place on disk where the files “are”, nothing stored, nothing to clear. What there is instead is a saved Spotlight search, and it ships inside Finder itself:

/System/Library/CoreServices/Finder.app/Contents/Resources/MyLibraries/myDocuments.cannedSearch

The bundle is still named myDocuments — this is the old All My Files under a new label, right down to its allMyFiles.icns. Its Info.plist identifies it as com.apple.canned-search.15 with CFBundleName and CFBundleDisplayName both still myDocuments. The word on the sidebar comes from somewhere else: not the (empty) en.lproj folder, but Resources/InfoPlist.loctable, which carries every language in one file:

$ plutil -p "/System/Library/CoreServices/Finder.app/Contents/Resources/\
MyLibraries/myDocuments.cannedSearch/Resources/InfoPlist.loctable"
"en" => { "CFBundleDisplayName" => "Recents" }
"de" => { "CFBundleDisplayName" => "Zuletzt benutzt" }

Inside it, Resources/search.savedSearch holds one query. On macOS 26.6 (build 25G72), plutil -p prints it verbatim:

(kMDItemLastUsedDate = "*") && ((kMDItemContentTypeTree = public.content) ||
 (kMDItemContentTypeTree = "com.microsoft.*"cdw) || (kMDItemContentTypeTree = public.archive))

Two conditions joined by &&. The same plist sets the scope, in a RawQueryDict alongside a second copy of that query:

"RawQueryDict" => {
  "SearchScopes" => [ 0 => "kMDQueryScopeMyFiles" ]
  "UserFilesOnly" => true
  "FinderFilesOnly" => true
}

Nothing about this is a folder. No directory on your disk backs that sidebar item — there is nothing inside it to repair, and no cache of yours to clear. There is a query, and it either matches your files or it does not.

Condition one: last used, not last saved

Recents wants to know exactly one thing about a file: have you ever opened it. Not whether you saved it. Not whether you downloaded it five minutes ago. Not whether you edited it this morning from inside an app that never handed it to Finder. Opened — the way you open a document by double-clicking it.

A file nobody has ever opened is not a candidate for that list at all, however new it is and however obviously it is sitting there in Downloads.

The bit of bookkeeping behind that is a single date macOS keeps on every file, called kMDItemLastUsedDate. Apple defines it in one line of its own metadata schema, in schema.strings inside the Metadata framework:

"kMDItemLastUsedDate"             => "Last opened"
"kMDItemLastUsedDate.Description" => "Date when this item was last used"

Last used. If nothing has ever opened the file, that date does not exist — and Recents is asking for files where it does.

Want to see it for yourself? It takes about a minute. I made two identical text files in the same second, opened one of them, and left the other alone:

$ mdls -name kMDItemDateAdded -name kMDItemLastUsedDate opened-later.txt never-opened.txt
kMDItemDateAdded    = 2026-08-08 09:46:22 +0000
kMDItemLastUsedDate = 2026-08-08 09:46:47 +0000
kMDItemDateAdded    = 2026-08-08 09:46:22 +0000
kMDItemLastUsedDate = (null)

Then I ran Finder’s own Recents query against the folder holding both:

$ mdfind -onlyin ~/mdtest-recents '(kMDItemLastUsedDate = "*") && ((kMDItemContentTypeTree = public.content) || (kMDItemContentTypeTree = "com.microsoft.*"cdw) || (kMDItemContentTypeTree = public.archive))'
/Users/me/mdtest-recents/opened-later.txt

One file. The other exists, is indexed, has a date added one second earlier, and is invisible to Recents because nothing ever opened it. That is the whole of the download complaint, and it has a page of its own.

Condition two: three categories that can never appear

The second half of the query is the part nobody publishes, and it excludes things outright.

An item has to conform to public.content, public.archive, or a com.microsoft.* type. mdls -name kMDItemContentTypeTree tells you what any given file conforms to:

Item	Content type tree contains	Eligible for Recents
.txt, .pdf, .jpg, .pages	public.content	yes, once opened
.zip, .dmg, .pkg	public.archive	yes, once opened
a folder	public.folder, public.directory, public.item	never
an app bundle	com.apple.application-bundle, public.directory, public.executable	never
an unrecognised extension	dyn.…, public.data, public.item	never

That last row is the one that catches people. Give a file an extension macOS has no type for and it gets a dynamic UTI conforming only to public.item and public.data. I created weird.qqzz and opened it — with open -a TextEdit weird.qqzz, because plain open refuses a file no app claims (kLSApplicationNotFoundErr) — and confirmed kMDItemLastUsedDate was set on it afterwards. It still did not come back from the Recents query, while a query on kMDItemLastUsedDate alone returned it happily. The file passed condition one and failed condition two.

So “I definitely opened it and it is not there” is not always a contradiction.

The scope keys narrow it once more. UserFilesOnly and FinderFilesOnly are both true, and the scope is kMDQueryScopeMyFiles — which, for what it is worth, is not a public MDQuery scope constant at all. MDQuery.h in the macOS SDK exports six: kMDQueryScopeHome, kMDQueryScopeComputer, kMDQueryScopeNetwork, and the AllIndexed / ComputerIndexed / NetworkIndexed variants added in 10.6. kMDQueryScopeMyFiles is none of them; it is Finder’s own. I could not confirm from the terminal exactly what it resolves to, so treat it as “your files” rather than “this Mac”, and do not expect an external drive to show up there.

The one-minute test that tells three faults apart

Pick a file you are certain you opened today and that is definitely missing from Recents. Run:

mdfind -name "part-of-the-filename"

What happens	What it means	Where to go
It prints the path	The index is alive. The Recents query is excluding the file.	Condition one or two above
It prints nothing, and nothing else in that folder is found either	The index is dead, or the folder is excluded from it	The next section
It prints the path and Recents has plenty of other files in it	You are probably not looking at Recents	The section after that

That single command is the fork in the road. Almost every wasted afternoon in this area comes from skipping it and rebuilding the index for a problem the index never had.

If mdfind comes back empty

Check the index status — and check it correctly, because the obvious command lies:

$ mdutil -s /
/:
	Indexing disabled.

$ mdutil -s -a
/:
	Indexing disabled.
/System/Volumes/Data:
	Indexing enabled.
/System/Volumes/Preboot:
	Indexing enabled.

-a walks every mounted volume, so the exact list varies with what you have plugged in; the line that matters is always /System/Volumes/Data. On a modern Mac the startup volume is a sealed, read-only system volume; “Indexing disabled.” on / is normal and means nothing about your files. Your home folder is on /System/Volumes/Data — df -h ~ will confirm it — and that is the line to read. Passing a folder instead of a volume gives you a third red herring: mdutil -s ~ returns Error: unknown indexing state. on a healthy machine.

If the data volume really does say indexing is off, or the index is corrupt, Apple documents the repair properly and there is no point in my restating it: Rebuild the Spotlight index on your Mac. Re-indexing a large volume takes hours, and Recents stays empty for the whole of it.

One quieter cause worth ruling out first. In System Settings ▸ Spotlight there is a Search Privacy… button, described in Apple’s own strings as “Prevent Spotlight from searching these locations.” Anything listed there is not indexed, so nothing inside it can ever reach Recents — and a folder can end up in that list from a decade-old troubleshooting session you have forgotten. Recovered files, restored backups and items copied off a Time Machine volume also arrive without a usage history, which is its own class of “Spotlight finds it, Finder doesn’t”.

If mdfind finds it and Recents still does not

Then the index is fine and the query is doing its job. It is worth seeing the scale of what the query discards. Three counts over the same folder do it — how much is indexed, how much has ever been opened, and how much survives both conditions:

mdfind -onlyin ~/Downloads 'kMDItemContentModificationDate = "*"' | wc -l
mdfind -onlyin ~/Downloads 'kMDItemLastUsedDate = "*"' | wc -l
mdfind -onlyin ~/Downloads '(kMDItemLastUsedDate = "*") && ((kMDItemContentTypeTree = public.content) || (kMDItemContentTypeTree = "com.microsoft.*"cdw) || (kMDItemContentTypeTree = public.archive))' | wc -l

Run on my Mac on 8 August 2026, that gives:

Folder	Indexed items	Ever opened	Match the Recents query
~/Downloads	4,783	423	267
~/Desktop	391	100	76
~/Documents	537	21	9

Your own numbers will differ, and mine drift by a few files a day — the shape is the point. Five and a half per cent of Downloads is eligible for Recents. The rest is not missing; it was never a candidate.

This is also why the usual advice fails. Sorting does not widen a query. Finder’s search UI overrides six attribute names, and the mapping is unambiguous:

"kMDItemLastUsedDate"        => "Last opened date"
"kMDItemFSContentChangeDate" => "Last modified date"
"kMDItemContentCreationDate" => "Created date"

Switching the Recents window’s sort to Date Added — via View ▸ Sort By, or by clicking the column header in list view — rearranges those 267 items. It cannot summon the other 4,516. Sort order and membership are different things, and Recents keys membership on the attribute Finder labels “Last opened date”.

If the window is showing something else

The third fault is not a fault at all. Finder ▸ Settings ▸ General has New Finder windows show:, and if that has been changed you may simply not be opening Recents any more — or, in the opposite complaint, you may be opening nothing else. That trade-off has its own page. The sidebar item can also be switched off, in the Sidebar pane of the same settings window — the checkbox list there is a real Finder surface, and unticking Recents removes the entry without touching a single file. And a window that still says Recents in its title bar while carrying a term in the search field is showing you the search, not the list.

Rebuilding Recents the way you meant it, for free

If what you wanted was “files that arrived recently” rather than “files I opened recently”, macOS will give you that without an app.

1. In Finder, choose File ▸ New Smart Folder.
2. Click + to add a criterion.
3. Set the attribute to Last modified date or Date added — not Last opened date, which is the one that produced your empty window. Finder’s first popup carries only a short list; if the one you want is not on it, pick Other… at the bottom and choose it from the full metadata list there. Then set the condition to within last, and a number of days.
4. Click Save, name it, and tick Add To Sidebar.

macOS’s schema names those two attributes kMDItemFSContentChangeDate and kMDItemDateAdded, and describes the second as “Date when this item was last moved” — which is exactly what a download or a save into a folder is. The result is an ordinary .savedSearch file of your own, structurally the same thing as the one Finder ships, and you can inspect it with the same plutil -p command used above.

That covers most people. It is worth saying plainly, because the rest of this section does not.

What FileBo shows instead

A Smart Folder is still a Finder window. You have to go and open it, and once you have, it is one more window sitting on top of the ones you already had.

FileBo works the other way round. You press one key — ⇧⌘F — and a small panel appears over whatever you are doing, including over a full-screen app. Click back into your work and it disappears on its own. You never go looking for it; it comes to you and then gets out of the way.

What is in that panel is the part that matters here. Everything you have touched lately, opened or not. The file you downloaded this morning and never got round to. The one an app saved for you. The one somebody sent you. Folders too — the ones Recents will not show you no matter what. Look back five months if you like, or narrow it to today. Open a file from there, or drag it straight into an email or a chat without going near Finder.

That is the whole of it. If you would rather not read another word about metadata, you have everything you need.

If you do want the mechanical version: FileBo keeps no database of its own and scans nothing. It asks the same Spotlight index Finder asks — it simply accepts four dates where Recents accepts one:

(kMDItemContentCreationDate >= $time.now(-150d)) || (kMDItemFSContentChangeDate >= $time.now(-150d)) ||
(kMDItemFSCreationDate >= $time.now(-150d)) || (kMDItemDateAdded >= $time.now(-150d))

kMDItemLastUsedDate is not among them, and that is the entire difference: a file that arrived counts as recent, whether or not you ever opened it. The window is a slider from 30 to 150 days, it narrows to the last 24 hours, 7 days or 30 days, and it holds up to 2,000 items.

One thing it cannot do, and it decides whether this page was any use to you: FileBo does not repair the Spotlight index. It reads that index, so if the index is broken, FileBo is just as blind as Finder. If mdutil -s -a told you indexing is off, fix that first — every one of these tools starts working again at the same moment, and no panel from anyone is a substitute.

If your actual question is narrower — this morning’s downloads, specifically — finding recently downloaded files on a Mac is the shorter road.