macOS 27 broke the menu bar click. Here is why, and the fix.
Apple shipped macOS 27 Golden Gate on 14 September 2026, and it broke one thing that matters to anything living in your menu bar, including both of our apps, and every other app built the same way. It is fixed. This page is the unvarnished version: what changed, what we did about it, and which build you need to have.
Both apps, on macOS 27, today.
The only thing you really need from this table is the version number. If the copy on your disk is older than that, it still has the old behaviour: an app does not update itself by being restarted.
v0.264.3 Left click on the menu bar icon opens the popover again; widgets, global hotkeys and
the local MCP server unchanged. v0.64.0 The same tray fix, plus full-screen, per-monitor and region captures taken through the
system capture path. Measured, not assumed. n/a It has no menu bar icon and does not capture the screen, so neither change touches
it. Your left click started behaving like a right click. It was not your mouse.
On macOS 27, clicking the menu bar icon of an affected app pops open the context menu (the one that should need a right click), and whatever the icon was supposed to do never happens. The keyboard shortcut still works, which is why it reads as “the click is wrong” rather than “the app is frozen”.
The cause sits one level below any of these apps. A Tauri app does not attach a handler
to the status bar item itself: the tray-icon library lays an invisible subview over the button, and that single subview does two jobs: it emits the click event, and
it keeps AppKit from opening the menu on its own. In macOS 27 the subview stopped receiving
the mouse press, so both jobs failed at once: the menu opens by itself and the
action never runs.
That is why it hits every Tauri app with a tray menu and not just ours. We reproduced it in a thirty-line Swift lab containing none of our code, before changing a single line. That is the part that told us it was the OS, and not a regression in our own release.
Looking for menu bar apps that already behave on 27? Ours are free, and we keep the list of what we verified: our menu bar apps on macOS 27.
macOS 27 may ask again before a full-screen capture, and the screenshot still works.
On macOS 27 a system panel can appear when an app captures the entire screen without going through Apple’s own picker, asking whether to let it “bypass the system private window picker”. It is new, it is Apple’s, and it is not an error: we measured the capture completing normally with the panel on screen, and the Screen Recording permission you already granted stays granted.
The app never answers that panel for you, and no build of ours tries to suppress it. What we do not know yet is how often it shows up in day-to-day use: that needs real usage to answer, not a guess. If it turns out to be frequent, the alternative is to route captures through Apple’s picker, and that changes how taking a screenshot feels, so it is a decision we would rather make in the open than quietly.
Screenshots no longer go through APIs Apple marked obsolete.
The two system calls a Rust screenshot library reaches for by default are marked obsoleted in macOS 15.0 in the SDK headers that ship with macOS 27. The symbols are still there, they still capture correctly today, and code calling them still compiles, which is precisely the problem: nothing warns you, right up to the release where Apple removes them and a screenshot app starts returning black frames.
So on macOS the image is now always taken by screencapture, the system’s own
binary, which already goes through ScreenCaptureKit. Display geometry
(how many screens you have, where they sit, their scale) still comes from the older call, because
that one is not deprecated. It is a change you should never be able to see, which is the
whole point of making it before it becomes urgent.
CGDisplayBounds: not deprecated, still
exact.
macOS 27 needs an M1 or newer. Your Intel Mac is not left behind here.
Golden Gate drops Intel, so every Intel Mac stops at macOS 26, and that is exactly the case a fix like this one tends to break, by branching on the OS version and quietly rotting the old path. There is not one version-gated branch in either app: the same build serves macOS 12 through 27.
Staying on macOS 26 for good? Here is what still runs on it, and what to expect from now on: free tools for an Intel Mac on macOS 26.
Webstarted Toolbox
macOS 12+, universal build: runs natively on Intel and on Apple Silicon. Plus Windows 10+.
Webstarted Screen Capture
macOS 12+, Apple Silicon. The Mac build is arm64 only, a limit of its own, with nothing to do with macOS 27. Plus Windows 10+.
Questions, answered.
Do Webstarted Toolbox and Screen Capture work on macOS 27 Golden Gate?
Yes. Both were run on macOS 27.0 (Darwin 27, build 26A428) on real hardware rather than assumed to be fine, and both ship a fix for the one thing macOS 27 genuinely broke: the left click on the menu bar icon. Toolbox is fixed from v0.264.3 and Screen Capture from v0.64.0. Everything else (capture, annotation, hotkeys, the local AI, the widgets) behaves exactly as it did on macOS 26.
Why did clicking my menu bar icon start opening the right-click menu?
Because macOS 27 changed which view receives the mouse press on a status bar item. Tauri apps do not attach a handler to the item itself: the tray-icon library lays an invisible subview over the button, and that one subview does two jobs at once: it emits the click event, and it stops AppKit from opening the menu on its own. In macOS 27 the subview stopped receiving the press, so both jobs failed together: the menu opens by itself and the action never runs. It looks like your left click turned into a right click, and it is not your Mac, your mouse or your settings.
Is that bug specific to Webstarted apps?
No, and that is worth saying plainly. It affects every Tauri application with a tray menu that opens something on left click, which is a very common pattern for menu bar apps. We reproduced it in a thirty-line Swift lab with none of our code in it. So if another menu bar app of yours started behaving the same way after you updated, this is almost certainly why, and the fix has to come from that app, not from a setting on your Mac.
What was the fix, exactly?
It comes from upstream: tray-icon 0.25.1 attaches the menu to the status item only while the menu is actually being shown, so the rest of the time the subview gets its clicks back. Tauri still pins an older minor of that library, so rather than wait for that to move we vendored the pinned version with that single upstream commit applied and nothing else. It comes back out the day Tauri moves to 0.25.1 or newer.
macOS 27 asked me to "bypass the system private window picker". Should I allow it?
That is your call, and the app deliberately does not make it for you. It is a new macOS 27 consent panel that can appear when an app captures the whole screen without going through the system picker, and it is not an error: we measured the screenshot arriving complete with the panel on screen, and the Screen Recording permission you already granted stays granted. How often it shows up in normal use is something we are still measuring, because the alternative (routing every capture through Apple’s picker) would change how taking a screenshot feels.
Does Screen Capture still use APIs Apple deprecated?
No. On macOS the image is now always taken by the system screencapture binary, which already goes through ScreenCaptureKit. The two older calls a Rust screenshot library reaches for by default are marked obsoleted in the macOS 15.0 headers; the symbols still exist in macOS 27 and still work, but code leaning on them is one Apple release away from breaking silently or returning black frames. The only thing still coming from the old side is display geometry, which is not deprecated.
My Mac cannot install macOS 27. Do your apps still work?
Yes. macOS 27 needs a Mac with an M1 chip or newer, so every Intel Mac stops at macOS 26, and that is exactly the case a fix like this one tends to break, by branching on the OS version and quietly rotting the old path. There is not one version-gated branch in either app. Toolbox supports macOS 12 and up and ships a universal build that runs natively on Intel and Apple Silicon. Screen Capture requires Apple Silicon on the Mac, which is a separate limit that has nothing to do with macOS 27.
I am on macOS 27 and the icon still misbehaves. What do I check?
The version you actually have installed. The fix ships in Toolbox v0.264.3 and Screen Capture v0.64.0, and an older copy on your disk keeps the old behaviour no matter how many times you restart it, because quitting and reopening an app does not update it. Download it again from the buttons on this page, replace the app, and the left click opens the window again.
Does anything about macOS 27 change what leaves my computer?
No, and nothing about this changed. Toolbox widgets run locally, Screen Capture keeps your screenshots on your own disk, and the optional AI that reads a capture talks to a model running on your machine. What macOS 27 changed is how the system hands an app your clicks and your screen, not where any of it goes afterwards.
Get the builds that handle macOS 27
Free, no account. If you already have either app installed, download it again and replace it: the fix ships inside the app, not in a setting.