Color Label logic is broken when manually renaming a file

[Mikey666]

Hi,
For many many years I have built and used a system to rename and process (mostly move - or not move - a file to different folders) files based on Color Labels. This system is now broken.

For example:
- if Color label is not Yellow, Red, or Green, rename file and Set color label Yellow.
- if Color label is Yellow or Red don't Move it. If Color label is Green move it.

Due to vacation I can not say exacly when, but recently this logic breaks when I manually rename a file Hazel has already processed. I have some edge cases where Hazel's logic becomes too complex to automatically rename the file correct, so I manually ajust the name after Hazel has processed it. But this does not work now, because as soon as I ajust the name of the file the Color labels are removed (by macOS/Finder I guess) and Hazel sees a new file and jumps in and changes the name "back" and adds the intial Color labels.

I use Color labels for several actions after the initial Rename action rule, not just to flag that the file has been renamed.

It there a way to keep my Color label logic so I don't need to rework my entire Hazel workflow?

Hazel: 6.1.1
macOS: 26.2 (25C56)

[Mr_Noodle]

Please go through the troubleshooting guide here: https://www.noodlesoft.com/kb/hazel-tro ... ing-guide/

Report back with the results of the diagnostics described there,

[Mikey666]

Dear Mr Noodle,

Please don't give up your fantastic work:-) The issue is (as so many times before, not in Hazel but) in Finder, so the Hazel troubleshooting gives no furhter clues of the problem. Here is what I found with verified root cause:

Summary:
Renaming a file in Finder on macOS Tahoe causes Finder to silently remove the file's color tag (and related xattr). This breaks a long-standing Hazel workflow pattern where a color label is used to prevent a rule from reprocessing a file.

My Hazel rule:
The rule matches PDF files that do NOT have a Yellow color label, checks file contents, renames the file based on a pattern, and sets the color label to Yellow. The Yellow label then acts as a guard — preventing the rule from matching the file again. This has worked perfectly for ~10 years across many macOS versions.

The problem:
Since upgrading to macOS Tahoe, whenever I manually rename a file in Finder (e.g. to make a small correction), the Yellow color label disappears. This causes the Hazel rule to match and reprocess the file, resetting the filename.

Verified root cause — Finder in Tahoe strips tag-related xattr on rename:

I paused Hazel and ran diagnostic tests using `xattr` in Terminal. Results:

Before Finder rename:

Code: Select all

com.apple.metadata:_kMDItemUserTags: bplist00..VACAB.0  (tag present)
com.apple.FinderInfo: 00 00 00 00 00 00 00 00 00 0A 00 00 ...  (byte 9 = 0x0A = Yellow label)


After renaming the file in Finder (Hazel paused):

Code: Select all

com.apple.metadata:_kMDItemUserTags: No such xattr  (GONE)
com.apple.FinderInfo: No such xattr  (GONE)


Other xattr survived the rename:
- `com.apple.lastuseddate#PS` — preserved
- `com.apple.macl` — preserved
- `com.apple.metadata:kMDItemFinderComment` — preserved
- `com.apple.provenance` — preserved
- `com.apple.quarantine` — preserved
- `com.noodlesoft.Hazel.RevertData` — preserved
- `com.readdle.LastPosition` — preserved

So Finder selectively removes `_kMDItemUserTags` and `FinderInfo` while preserving all other xattr. This is not a filesystem issue — it is specific to Finder's rename operation on Tahoe.

Conclusion:
This is a macOS Tahoe bug. Finder's rename operation strips tag-related extended attributes (`com.apple.metadata:_kMDItemUserTags` and `com.apple.FinderInfo`) while preserving other xattr. This breaks any workflow — including Hazel rules — that relies on color labels or tags persisting across manual filename edits.

Related reports of Tahoe metadata/xattr issues:

1. Apple Community — "Tahoe Finder Missing Video Duration": Users confirm that renaming or duplicating files in Finder on Tahoe causes metadata to disappear. One user states: "changing anything about a pre-Tahoe file with visible details makes those details disappear — even just renaming it."
https://discussions.apple.com/thread/256138771

2. Apple Community — "Tags disappear in Finder" (Tahoe 26.0.1): Users report tags vanishing spontaneously on Tahoe.
https://discussions.apple.com/thread/256181676

3. Eclectic Light Company — "Which extended attributes does macOS Tahoe preserve?" (Dec 2025): Technical analysis of how Tahoe changed xattr preservation behavior during file operations.
https://eclecticlight.co/2025/12/17/whi ... -preserve/

[Mr_Noodle]

Sorry, I misread your post.

That's unfortunate. Note that Hazel does not use Finder to do the renaming so if you can figure out how to get Hazel to handle those edge cases, that might get around it. If you give me more details on these edge cases, I can try and come up with some possible approaches.

[Mikey666]

Thanks for the suggestion.

The edge cases involve manual corrections after Hazel processes invoice filenames—specifically when capturing amounts that aren't consistently formatted, even from the same vendor. For example, Apple invoices vary wildly: thousand separators might be ".", ",", or space (or absent entirely), decimal separators are inconsistent (we use comma in Sweden), and currency indicators ("kr", "SEK", or nothing) appear before or after the amount. I've tried many pattern variations but haven't achieved reliable extraction. I haven't explored regex yet, though.

Rather than trying to get Hazel to handle these formatting variations perfectly, I'm considering a workaround for the underlying Tahoe bug: replacing color labels with Spotlight Comments as workflow state markers. Since Comments survive Finder's rename operation while color tags get stripped, I can use keywords like hazel:processed, hazel:skip, and hazel:archive in the Comments field to prevent reprocessing after I manually correct filenames in Finder.

What do you think is the best way forward? I currently have around 250 active rules that will need to be updated

[Mr_Noodle]

You could try different patterns under a nested condition. There might be a lot of combinations though.

If comments work, then I'd suggest that. If you have 250 rules though, I'd look into consolidating those. Do they follow a similar pattern? If so, you might want to look into using things like custom list item or table attributes.