On macOS Sequoia and later versions, a system prompt appears when an application first attempts to access devices on a local network. While these decisions are intended to be persistent, many applications trigger repeated prompts because their installation paths change or they utilize temporary folders for updates—common behaviors in Chromium-based browsers like Chrome and Brave. Because there is no standard way to pre-deny these permissions via Mobile Device Management (MDM) payloads or common command-line tools, users often face repetitive dialogs that clutter privacy settings with duplicate entries.
The `dontallow` tool addresses this by acting as a lightweight agent that monitors the `UserNotificationCenter` process. It registers an Accessibility observer specifically looking for window creation events from that process. When it detects a prompt asking if an app can find devices on a local network, it verifies the text content and automatically triggers a click on the "Don't Allow" button. The developer designed the tool to use zero CPU while idle and survive reboots by running as a launchd agent. To ensure safety, the tool never chooses the "Allow" option; instead, it provides a mechanism for users to manually whitelist specific apps or pause its activity temporarily if they need to grant legitimate access to features like AirPlay or Chromecast.
This image represents the source repository for the dontallow tool described in the article.
While effective at reducing friction, the utility relies on macOS Accessibility permissions, which grants the software significant control over UI interactions. This creates a trade-off between convenience and security: using such a tool requires granting high-level privileges to an unverified third-party binary. Furthermore, because the tool operates by matching dialogue strings rather than underlying system IDs, it is currently limited to English-localized versions of macOS. Users who require these prompts to be dismissed but want more granular transparency may still face challenges, as the current implementation focuses on automated rejection rather than explaining why a specific application triggered the request in the first place.