Troubleshooting
When two apps fight over the same display setting
Your brightness drifts. Your colour looks wrong an hour after you set it. Nothing in your settings changed — because a second tool is writing to the same place, and neither side knows.
The places a second tool can write
Display state is not one value. It is a handful of separate domains, and each one is somewhere another utility can quietly write: a menu-bar app, a helper process, a script. Both of you believe you own it.
Detecting the other app is the hard part
Matching by display name is unreliable. Vendors ship a menu-bar app plus helper processes, and the helpers often carry no useful name at all. So the reliable signal is the bundle identifier prefix, with an exact localised name as a second pass for tools whose bundle id is undocumented.
Why a miss is better than a false alarm
A tool that matches neither test stays undetected, and that is deliberate: a warning that never fires is better than one that fires on an unrelated process. A conflict warning you learn to ignore is worse than no warning at all.
What to do about it
- If two apps both claim brightness, pick one and disable the other. There is no arbitration protocol between them — the last writer wins, and which that is depends on timing.
- Check for helper processes, not just the app in your menu bar. The helper is often the one writing.
- If the drift happens after sleep or a display reconnect, it is probably not a conflict at all but a panel that needs a moment before it answers again.
Honest limits
- This page describes how one implementation detects rivals. It is not a standard, and it cannot see a tool whose bundle id and name both fail to match.
- “Last writer wins” is a description, not a guarantee. Two tools writing in an interleaved order can produce a state neither of them intended.