Should I vibe code
Hide, reveal, and arrange menu-bar items with user-defined rules
Hiding menu bar icons is not a subscription-shaped problem.
?
Their verdict, the Bartender licence price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A small always-running utility with no network access and no data. Worst case it crashes and your menu bar looks normal again.
What actually breaks
not "if". the specific failures.
- The menu bar itself, which macOS does not offer a supported API to rearrange — so this category lives on undocumented behaviour
- Every OS release, which is when undocumented behaviour stops working, usually the week you upgrade
- Notch-era geometry, where the usable bar is shorter than the screen and items disappear behind it
- Multi-display and resolution changes, which reshuffle everything you carefully arranged
- Accessibility permissions, without which the whole thing silently does nothing
There is no incident here worth dramatising, and pretending otherwise would be dishonest — the realistic version is a Tuesday in October. You update macOS, the menu bar comes back full of icons you had hidden for a year, and the technique you were using no longer works at all. The fix is not a bug fix; it is finding a new approach to something the platform never promised. That is the actual cost of this project, and it recurs annually.
Is that you?
the verdict is a default, not a law
- You accept that an OS update may break it entirely and you will fix it or stop
- It only hides and arranges — it reads nothing and sends nothing
- It is on your own machine and nothing depends on it working
- You need it to keep working without attention across OS upgrades
- You would ship it to other people who expect support
- It manipulates other applications beyond the menu bar
If you build it anyway
the checklist, then the prompt that enforces it
- Expect to rewrite this every major OS release. That is not a flaw in your approach, it is what building on undocumented behaviour means.
- Fail visibly and safely: if the technique stops working, show every icon rather than hiding them all or crashing.
- Never manipulate other applications beyond the menu bar. Scope creep here turns a harmless utility into an automation tool with permissions.
- Handle display changes and resolution switches explicitly, and re-derive layout rather than caching coordinates.
- Detect missing accessibility permission and say so, because otherwise it simply does nothing.
- Keep the configuration in a plain file so a rewrite next autumn does not lose your arrangement.
Before you build a menu bar manager, apply these and push back if I ask you to break them. 1. Tell me upfront that macOS provides no supported API for rearranging or hiding other applications' menu bar items, that any working approach relies on undocumented behaviour, and that a major OS release can remove it entirely. This is the defining fact about the project. 2. Fail open: if the technique stops working, reveal all items rather than hiding them, crashing, or leaving the bar in a broken state. 3. Scope strictly to the menu bar. Refuse to extend into manipulating windows, sending events to other applications, or automating anything, and explain that the permissions this needs would then be doing much more. 4. Recompute layout on display connect, disconnect and resolution change rather than caching coordinates. Handle the notch geometry explicitly. 5. Detect a missing or revoked accessibility permission and tell the user clearly, since the failure mode is otherwise a utility that silently does nothing. 6. Store configuration in a readable plain file so it survives a rewrite. 7. Do not read the contents of other applications' menus — position and identity only. 8. Put a line in the README stating which macOS versions this has been tested on and that it will likely break on the next one.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Bartender is a one-off purchase and its actual value is that someone else absorbs the annual breakage. Build your own if you enjoy that particular chase; buy it if you want your menu bar tidy without thinking about it every October.
Keep the configuration in a plain file and accept that the implementation is disposable. When an OS release breaks it, the arrangement you liked is the thing worth keeping; the code that achieved it was always temporary.
Active open-source cross-platform text expansion utility with system integration.
Questions
If it relies on undocumented behaviour, why is this SHIP IT?
Because the failure costs nothing. When it breaks, your menu bar is untidy — no data is lost, nobody else is affected, and the fix is optional. That is exactly the profile the verdict describes: worst case you delete the repo. The annual breakage is a maintenance cost, not a risk.
Why does failing open matter so much here?
Because the failure will happen while you are doing something else, probably right after an update. Hiding everything or crashing leaves you without access to menu bar items you actually need. Revealing everything is mildly annoying and completely recoverable, which is the correct behaviour for a utility whose whole job is cosmetic.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice