Hazel: the setup order that holds up

Adding one rule to Hazel takes about three minutes. Getting the order of the whole setup right is the part that decides whether the thing is still running in six months or sitting there disabled. Most of the confusion around Hazel tsukaikata is not about what a rule can do. It is about which decision comes first, because by the time a rule is wrong, files have already moved. What follows is the order that causes the least backtracking, based on what the published manual states about how rules are evaluated.

Start with the folder, not the rule

The first decision is which folder gets watched. Everything downstream depends on it, and it is the decision most people skip because the rule editor is the interesting part.

Pick one folder where files arrive without being placed there deliberately. Downloads is the obvious candidate. So are the Desktop, a scanner destination, and wherever screenshots land. These are inboxes, and an inbox is the only kind of folder where an automatic move is low risk, because nothing there has been filed yet. A folder that already holds sorted work is the opposite case. A rule that fires there moves something that was already in the right place.

Hazel can also watch Smart Folders, which means rules can act on any file that matches a saved search rather than any file in one physical location. The manual notes this works with minor limitations. That flexibility is useful later. It is a poor place to start, because when nothing happens there are now two things that could be wrong, the search and the rule, instead of one.

Before writing anything, count what is in the folder. A rough tally by extension and by age gives a baseline. When a rule runs and fifty files move, the count is how you confirm that the fifty were the right fifty. Without it, the only evidence is that the folder looks emptier, which is not the same thing.

One folder is also the right starting size for a different reason covered further down: the unregistered version eventually limits you to exactly one.

Only the first matching rule runs

This is the single behaviour that explains most unexpected results, and it is worth reading twice.

Hazel takes the first rule in the list and tests it against the first item in the folder. If the conditions match, it runs that rule's actions in order and then moves to the next item. If they do not match, it tries the next rule against the same item, and so on. The moment a rule matches, the remaining rules are skipped for that file.

The manual gives a clean example. One rule tags files starting with "A" red. A second rule opens .png files in Preview. A file named Apple.png gets the red tag and nothing else, because the first rule already matched. A file named Banana.png gets opened in Preview, because the first rule did not match. There is an action called "Continue matching rules" that overrides this and hands the file to the next rule. If that next rule matches, evaluation stops there too, unless it also carries the same action.

The practical consequence is that rule order is the design, not the conditions. Specific rules belong above general ones. A rule that catches PDFs whose names contain an invoice number goes above a rule that files every PDF into one folder. Reverse those two and the specific rule never runs, because every PDF matches the general rule first. This is the failure that shows up around rule number five, when the list is long enough that nobody remembers what is above what.

Check the match before the action runs

Saving a rule makes it live. There are two ways to see what a rule will catch before anything moves, and both are worth using on every rule that does something irreversible.

Preview a single file

With a rule open for editing, choose Rule then "Preview Rule", or press Command-Option-P, and pick a file in the watched folder. Hazel reports whether the rule as a whole matches. Each individual condition also shows a green check or a red X, and clicking either one shows the current value of that attribute on that file. That popover is where a date condition stops being a guess: it shows the actual date the file carries, which is often not the date you assumed. Preview only evaluates conditions. It does not run actions, and it works on rules that are currently disabled.

See the whole folder at once

The Rule Status view lists the files in the folder alongside which rule each one matches. Preview answers a question about one file. Rule Status answers the question about ordering, because it shows which rule is winning across the whole folder. When a specific rule appears to do nothing, this view usually shows a general rule sitting above it, taking everything.

When both look right and the behaviour is still wrong, the logs are next. Help then "View Logs", filtered by the file name in question. There is a debug mode that makes the logging far more detailed, which is the last step before contacting support with something concrete attached.

What Revert covers, and what it does not

Automation is only comfortable if mistakes are cheap. Hazel 6 added a Revert command, reachable by right-clicking a file in the Finder or from the menu bar icon. It restores the file to its original position and name, and it also restores properties such as tags and comments. It does not cover every action.

Revert applies to	Revert does not apply to
Move, Rename, Sort into subfolder	Copy, Sync, Upload
Add tags, Remove tags, Set color label	Make alias
Add comment, Toggle extension, Toggle lock	Import into Music, Photos, or TV
Archive, Unarchive	Running automations and scripts

The pattern is easy to hold in mind. Actions that change where a file sits or what it is labelled can be undone. Actions that create something outside the folder cannot, because there is nothing local to reverse. An upload has already left.

Use that split to sequence the build. Start with moves, renames, and tags. Let those run for a week. Add uploads, imports, and script actions only once the conditions have proved themselves against real files. The manual also adds a note worth keeping: after reverting, fix the rule, otherwise the file gets processed again on the next pass.

Subfolders sit outside the rule list until you let them in

Here is the second behaviour that produces silent nothing-happened results.

Hazel treats files and folders in the watched folder the same way, and it does not look inside subfolders by default. The manual's example uses Downloads with a subfolder called Research. A rule that opens PDFs in Preview fires for a PDF that lands in Downloads. The same PDF saved directly into Research does not trigger it, because the contents of Research are not being examined. Research itself is an item that rules can match, but its contents are not.

There are two ways in. Add each subfolder as its own watched folder, which works when the names are known and few. Or use the action called "Run rules on folder contents". A rule carrying that action, when it matches a subfolder, causes the rest of the rule list to be applied to that subfolder's contents as well. That is the option that survives subfolders you cannot name in advance.

Note where this rule has to sit. Because only the first matching rule runs, the go-into-subfolders rule must be above the rules that would otherwise catch a folder. Put it lower and a different rule matches the subfolder first, evaluation stops, and nothing inside is ever seen.

Permissions, the Trash, and the parts that need more access

During installation, macOS asks for permission to access certain folders and the manual instructs you to approve each prompt. Skipping one produces a setup that looks complete and does nothing, because the watched folder cannot be read.

Trash features need more than that. They require full disk access, granted in System Settings, and the installer raises a specific alert about it. Two features sit behind that permission. Automatic deletion removes items from the Trash once they have been there longer than a set period, or once the total size of the Trash exceeds a set limit, oldest first. App Sweep watches for applications being thrown away and offers to throw away the support files they leave behind.

Both are permanent deletion, not another move. The manual's own advice is to set the limits longer and larger than seems necessary on the first attempt, which is a reasonable way to find out what the folder actually contains before anything is lost.

It is worth knowing that macOS has a version of the first feature built in. The Finder can empty items from the Trash automatically after thirty days, with no extra permission and no rule. If thirty days is the right number, that setting is enough on its own. The reason to grant full disk access is wanting a different period, or wanting a size cap rather than a time cap, or wanting App Sweep. That is a real reason. It is just not an automatic one, and the trade-off is worth making deliberately rather than clicking through the alert.

The trial clock, the licence, and the second Mac

After fourteen days

An unregistered copy runs in Evaluation mode, where every feature except rule export is available. That lasts fourteen days. After that it becomes Demo mode, which watches one folder and allows two active rules, with import and export disabled.

This shapes how to evaluate it. Building out five folders and twenty rules during the trial means watching most of it switch off on day fifteen, with no clear sense of which parts were carrying the value. One folder and two rules is the configuration that still tells you something when the clock runs out, so it is worth deciding upfront which single repeated chore you are trying to remove.

What the licence covers

The store lists Hazel 6 at $42 for one licence, $65 for a family pack covering up to five members of a household, and $20 to upgrade from a previous version. It is a one-time purchase with a paid upgrade at major versions, not a subscription. Hazel 6 requires macOS 12 Monterey or later. Noodlesoft, the developer, marked twenty years since Hazel's first release in September 2026, which is a longer track record than most utilities in this category and also the reason older tutorials describe a System Preferences pane rather than the standalone app it is now.

Sharing rules with another Mac

Beyond one-time export and import, rules for a folder can be synced to an external file kept somewhere both machines can reach. Four caveats come with it. Syncing works on the complete rule set for a folder, never on individual rules. Enabled and disabled states are not synced. Newly added rules arrive disabled on the other machine and have to be switched on by hand. And syncing cannot merge two sets: pointing a second Mac at the file overwrites whatever rules it already had for that folder. Export the second machine's rules before connecting it.

What to change first

Pick the one folder where files arrive without being filed, write two rules that only move and rename, and put the more specific one above the more general one. Watch it for a week before adding anything that cannot be reverted. If the sorting works and the day still feels the same, the friction was never the filing, it was moving between a folder window, a terminal, and an assistant, which is a different problem and worth reading about in Features or against the alternatives in Compared with other file managers, including what Atriens costs.