フォルダの自動振り分け not working: what to check, in order

A sorting setup that worked yesterday does nothing today. Or it moves three files out of ten and leaves the rest sitting there. The instinct is to open the rule editor and start adjusting conditions, which is almost always the wrong first move, because the conditions are the bottom layer of a stack with four layers above them. Work from the top and most of these cases resolve in a couple of minutes.

The order below is arranged by how often each layer is the actual cause, and by how quickly each one can be ruled out.

Sort the symptom before touching anything

Three symptoms, three different sets of causes. Mixing them is what turns a five minute check into an afternoon.

Nothing moves at all. The cause is the mechanism or the permission. Conditions are irrelevant, because a rule that never runs cannot match anything.

Some files move and others do not. The cause is scope or file state. Certain items are outside what the rule watches, or they were in a different condition at the moment it fired.

Everything moves but lands in the wrong place. Now it is the rule. This is the only symptom where editing conditions is the right response.

Deciding which of the three is happening takes ten seconds and determines everything that follows. Changing a condition while diagnosing the first two symptoms destroys the ability to tell whether a fix worked, because the setup was never running the old condition in the first place.

Check one: the system switched the automation off

macOS 26 disables folder automations on its own under two circumstances, neither of which involves anyone changing a setting.

The first is the target folder being moved to the trash. The automation is disabled because the folder was moved to trash, and recreating a folder with the same name does not restore the link, because it is a different folder as far as the system is concerned.

The second is size. The maximum folder size is 10,000 items, and an automation is disabled once the target exceeds it. Anyone pointing a rule at a long lived downloads folder will meet this eventually. Moving older items into a dated archive brings the count back under the limit and the automation can be re enabled.

There is a third case that is not a disabled automation but looks identical from the outside. Automations can be set to run immediately or to ask before running. Set to ask, the automation waits behind a notification until someone approves it. Dismissed notifications look exactly like a setup that has stopped working.

Check two: the target is out of bounds

Some locations simply cannot be targeted. Folder automations cannot point at the trash, and they cannot point at external drives. An hour spent debugging a rule aimed at an external SSD is an hour spent on a restriction rather than a bug.

iCloud Drive introduces a subtler version of the same problem. With storage optimisation active, the contents of files that have not been opened recently are evicted from the disk and replaced by a small placeholder with a leading dot in its name. Visually there is still a file. Any condition that needs to read the file itself, including size and content matching, will not match a placeholder. Downloading the real contents first, or targeting a folder outside iCloud Drive, are the two ways out.

Subfolders are the third scope trap. Folder automations carry a setting to ignore subfolders, and with it enabled, anything one level down is invisible to the rule. Browsers that unpack multi file downloads into their own subfolder produce exactly this symptom: most files sorted, one batch untouched.

Check three: permission was revoked

Sorting tools reach into Desktop, Downloads and Documents, and macOS controls that access per app. It can be withdrawn by a system update, by replacing the app, or by someone clicking the wrong button on a prompt months ago.

The list lives in System Settings under Privacy and Security, in the Files and Folders section. If the entry for the relevant app is switched off, no condition will ever match, because nothing can be read. Full disk access is worth checking in the same visit, since some tools ask for it instead.

For anything driven by a script, the permission belongs to whatever launched the script rather than to the script itself. A shell script run from a terminal inherits the terminal's access. A script run by a scheduling job inherits the job's. Checking the wrong one gives a clean result while the real caller is still blocked. When an app is missing from the Files and Folders list entirely, it has either never asked or was refused at first launch. Toggling access off and on again forces a fresh prompt on the next run.

Check four: the file was not finished when the rule ran

This is the single most common reason some files sort and others do not.

While a download is in progress, the browser writes to a temporary name. Chrome appends .crdownload. Safari uses .download. A rule watching for added items sees that temporary item, fails to match it on extension, and moves on. When the transfer completes, the switch to the final name is a rename rather than an addition, so an added trigger never sees the finished file at all. Large files fail this way far more often than small ones, which is why the pattern often looks like "it skips video but handles PDFs".

Three fixes, in increasing order of reliability. Trigger on modification rather than addition. Add a delay before the rule acts. Or abandon immediate triggering and run on a schedule, at which point nothing is ever half written when the rule fires.

Rolling a custom watcher instead is worth a caution. The system documentation for scheduled jobs describes direct filesystem watching as race prone, notes that modifications can be missed entirely, and adds that a file is not guaranteed to be in a consistent state when the job launches. Scheduled runs sidestep all three problems.

Check five: the condition itself

Only now is the rule editor the right place to be. Four conditions account for most misses.

Extension case. Cameras and phones frequently write uppercase extensions, and a lowercase only condition skips every one of them.

Invisible characters in names. Full width spaces, full width parentheses, a trailing space. On screen they look identical to the ordinary versions. As match targets they are entirely different characters. Listing the folder in a terminal and comparing the names directly is the fastest way to see which is which.

Date fields. The creation date of a downloaded file is often the date it was created on someone else's machine, not the date it arrived. A rule that sorts items created within the last three days will skip a file that arrived this morning carrying a two year old creation date. Sorting by date added or by modification date matches what a person actually means.

Condition combination. Whether every condition must match or any one of them is enough, and whether the engine stops at the first matching rule or runs them all.

The method that works: take one file that did not move, and remove conditions one at a time until it matches. Whichever removal fixed it is the culprit. Adding conditions while trying to fix a miss produces a rule set nobody can reason about.

Confirm a fix the same way every time

Each change made during this process needs verifying, and the verification has to be identical each time or the results cannot be compared. Improvising a different test after every adjustment is how a setup ends up declared fixed while still broken.

Use a single probe file. Copy a real file of the type that is failing, put the current timestamp in its name so each attempt is distinguishable, and drop it into the watched folder. An empty text file is a poor probe: it will satisfy an extension condition while failing anything that inspects size or contents, which hides the very problem being chased.

Give the run the time it actually needs. An immediate trigger settles within seconds. A scheduled setup does nothing until its next run, and treating that gap as a failure sends people back to editing conditions that were never at fault.

Clear the probe files out afterwards. Leaving them at the destination guarantees a name collision on the following attempt, and a collision produces a skip or a replace that looks like a fresh bug. Writing these four steps down once turns every future incident into the same repeatable check.

When it is an Automator folder action instead

Folder actions predate the Shortcuts route and run through a different mechanism, so none of the checks above apply in the same way. Apple's guidance describes the setup step plainly:

To create an Automator workflow, you choose the type of workflow you want, and then add actions to it. Source: support.apple.com

Three places hold the answer when a folder action goes quiet. The setup app lives inside /System/Library/CoreServices/Applications/ and shows whether folder actions are enabled at all and whether the target folder is still attached. Hand written scripts belong in Library/Scripts/Folder Action Scripts inside the home folder, and a script in the wrong directory is attached to nothing. The dispatcher that does the actual watching runs from /System/Library/CoreServices/, and it is tied to a login session, so nothing fires while logged out.

When a file seems to have vanished

The most alarming symptom is a file that was definitely moved and is now nowhere. In most cases it was not lost in transit. Something with the same name already existed at the destination and the move replaced it.

The Finder sets the expectation here. When identically named files meet, the offered choices are stop or replace, with no automatic renaming to keep both. Sorting tools differ: some append a number, some replace, some skip and log. A setup left on replace will eventually remove something, and the files most likely to collide are the machine named ones people automate first.

Two habits prevent the repeat. Keep a plain text record of every move, with timestamp, source and destination, which turns a search into a lookup. And point sorted files at a dated staging folder rather than their final home, so an overwrite leaves at least one generation intact. Where Time Machine is running, opening the destination folder at an earlier point in time recovers the replaced copy.

What to change first

Run through the five checks in order and write down which layer turned out to be responsible: mechanism, scope, permission, timing, or condition. That one line is what makes the next occurrence a two minute job. Every one of these checks means moving between the Finder, System Settings and a terminal, which is its own cost, and the Features page covers how much of that round trip a single window removes. For how the rest of it compares with other approaches, Atriens sits alongside them.