Softwaremacosprivacychromechromiumlocal-networkopen-sourceswift
dontallow Auto-Clicks Don't Allow on the macOS Local Network Prompt Chromium Browsers Keep Re-Triggering From a Temp Folder
JP Cassil's open-source dontallow, two Swift files and a Homebrew install, watches for the macOS Sequoia-and-later Local Network permission dialog and presses Don't Allow within a fraction of a second, because Chrome, Brave, Edge and Arc keep bringing it back.

If you run Chrome on a recent Mac, you’ve probably seen it. “Allow ‘Google Chrome’ to find devices on local networks?” The dialog adds that this “will allow the app to discover, connect to, and collect data from devices on your networks.” You click a button, and a launch or two later it’s back.
Cassil’s README lays out why. Chrome, Brave, Edge, Island and Arc “copy their own app bundle into a random temp folder at launch so the code signature survives in-place updates. macOS keys the Local Network decision to that random path, so the next launch looks like a brand-new app.” The side effect shows up in System Settings, where “Your Privacy settings fill up with duplicate ‘Google Chrome.app’ rows that no longer point at anything.” Apps that install into versioned folders get a new row with every update, too.
Apple’s own documentation explains the plumbing from the other side. Technote TN3179 says Local Network privacy came to the Mac in macOS 15, that it “uses your main executable UUID as part of its implementation,” and that “Device managers aren’t able to configure local network privacy using MDM.” So an IT department can’t pre-answer the question for you.
dontallow doesn’t fight any of that. It answers the dialog. The prompt is a window owned by the system’s UserNotificationCenter process, and the agent registers an Accessibility observer for new windows there, sleeping until one appears. When one does, it reads the text, confirms it’s the Local Network prompt, checks whether you’ve paused it or allowlisted the app, and presses Don’t Allow. The README promises “Zero CPU while idle” and says it “never modifies system files, never disables protections, and never chooses Allow.”
Setup is two commands: brew install johncassil/tap/dontallow, then dontallow install, which writes a per-user launchd agent and walks you to the Accessibility setting it needs. After that, dontallow status shows recent dismissals, dontallow pause 10m steps aside while you grant access to an app that really does use the network, and dontallow rules decodes the system’s Local Network rule store to show what each Privacy row actually is, “including orphans.” App names you add to ~/.config/dontallow/allowlist are never touched. Each dismissal posts a notification naming the app and the pause command.
The README says there is “no supported way to prune the list,” and that tccutil reset doesn’t cover it. Apple’s technote now disagrees for its newest release: the Local Network list in System Settings “has add (+) and remove (-) buttons,” and “These buttons were introduced in macOS 27.2. On earlier versions of macOS there’s no way to reset your program’s Local Network privilege.” Cassil lists his own test machine as an Intel Mac on macOS 26.6, and the tool is English-only for now because it matches the dialog’s words and the Don’t Allow button title. Remove buttons can clear the dead rows Chromium leaves behind, but nothing in the technote says macOS will stop keying the answer to a temp folder that changes every launch.