macOS Local Network Prompt: Auto-Dismiss with dontallow

App paths can change between launches

The dontallow project calls out Chromium-based browsers - Chrome, Brave, Edge, Island, and Arc - as a common example. Per the project, some browsers copy their app bundle to a temporary directory on launch. That can help keep the code signature intact during in-place updates, but it also means the app may show up under a different path later.

If macOS records the Local Network decision against the path it saw last time, a new temporary path can look like a different app. So you get the prompt again even if you feel like you already answered. Over time, Privacy settings may also accumulate duplicate entries, including rows pointing to old or temporary locations.

This isn't the only scenario. Apps installed in version-specific directories can also end up with a new path after an update. The project also notes that macOS can attribute a prompt to an app that doesn't seem to be running. Put together, that means "the dialog returned" doesn't always mean "the app started using the feature for the first time" - it can also mean "app identity or path tracking shifted."

A denial is useful only if the app doesn't need the feature

Local Network access supports real things. A browser or media app might use it for Chromecast or AirPlay discovery. Games use it for LAN multiplayer. Printer and scanner utilities may need it to find hardware on your network.

If you depend on any of those functions, automatically denying the prompt can break the feature. If you don't use local-network functionality at all, then a recurring prompt is just noise. The right move depends on your actual usage - not the app's name.

The project also says there's no supported way to prune the Local Network rule list, no MDM payload to pre-deny it, and tccutil reset doesn't cover it. dontallow stays in its lane: it reacts to the visible prompt, rather than editing system databases or trying to alter macOS protections.

It observes the system dialog, then checks what it is

The prompt shows up in a window owned by UserNotificationCenter. The agent registers an Accessibility observer for new windows from that process. When a window appears, it reads the dialog text and verifies it's the Local Network prompt (not some other system dialog) before doing anything.

Then it checks two conditions: whether the agent is paused, and whether the requesting app matches an allowlist entry. If neither applies, it tries to trigger the Accessibility "press" action on the Don't Allow button. If that doesn't work, the project says it falls back to a synthetic click at the button's location.

This sequence matters: this isn't a global macOS setting that silently changes permission behavior for every app. It's UI automation targeted at that specific dialog, with controls to stop it when you don't want automatic denial. The project also says each dismissal generates a notification that names the app and reminds you how to pause the agent.

It requires Accessibility permission

Because the utility interacts with a system dialog, macOS requires Accessibility access. That's a meaningful permission - Accessibility-enabled software can interact with parts of the user interface. So you should treat granting it as an actual trust decision, not a routine "install and forget" checkbox.

The project says dontallow doesn't modify system files, disable protections, or pre-select Allow. Those choices limit what the tool is trying to do, but they don't remove the need to trust the binary you're installing and granting access to. If you build or distribute it yourself, verify what you're installing.

Its behavior is deliberately reversible

The agent can be paused temporarily or indefinitely, resumed, uninstalled, and configured with exceptions. That matters because denial can stop an app from doing the thing you later decide you want. A tool that automatically denies forever - with no real way to stop - would be a poor fit for this kind of permission workflow.

Install and confirm the agent

The documented commands are:

brew install johncassil/tap/dontallow
# Or build and install from source:
make && make install
dontallow install

During setup, macOS may ask you to grant Accessibility permission. If the expected entry doesn't show up automatically, the installer prints the exact path to add under System Settings > Privacy & Security > Accessibility. It then waits for the grant and reports when the agent is active.

Use dontallow status to check whether the agent is running, whether it's paused, what's on the allowlist, and your recent dismissals. If Accessibility access is missing, the status command repeats the permission instructions. In other words: you don't have to guess whether it's working.

Choose a control method that matches the app

You've got three documented ways to let an app use the local network:

• Run dontallow pause 10m, launch the app, and choose Allow yourself. The pause command accepts 30m, 2h, and 1d; forever leaves prompts alone until you resume the agent.
• Add the app's name to ~/.config/dontallow/allowlist (one entry per line). Matching is case-insensitive and uses substring matching, so pick a name that identifies the app you mean without accidentally matching something else.
• If you already dismissed the prompt, change the app's permission in System Settings > Privacy & Security > Local Network. A dismissal records a denial, and that's reversible there.

If you need a quick, one-off exception, a timed pause is often easiest. If you want a repeatable exception, the allowlist is convenient. The Local Network settings toggle is useful when you've already denied something and you just want access back.

Adjust timing, inspect rules, or stop the agent

The project supports a grace period via ~/.config/dontallow/grace. Set it to a number of seconds if you want time to click Allow before the agent acts; the documented default is 0.25 seconds. That's pretty short - adjust it if you want a more deliberate decision window.

dontallow rules reads the system's Local Network rule store and shows what the Privacy settings rows correspond to, including orphaned entries. If you want to see what it would do without actually pressing buttons, use dontallow run --dry-run to run in the foreground and log the actions. When you want the automation gone for good, dontallow uninstall stops and removes the agent.

A convenience tool can still break a feature

A dismissed prompt isn't just a notification you can ignore. It records a denial, and that can prevent the app from finding devices until you restore access.

If a feature suddenly stops working, check the Local Network settings for that app before you blame your router, printer, or media device.

In households or shared workstations, an allowlist can be more reliable than hoping nobody needs that permission at the same time. On the flip side, a broad allowlist match could exempt more prompts than you intended. Keep allowlist entries specific, and when you're unsure who's requesting access, use a temporary pause.

The notifications after dismissals give you a feedback loop: you can see which app was denied and decide if the action was right. If you find those notifications distracting, the project says they can be muted in System Settings. Muting them helps with noise, but you'll lose a useful signal - so if something is "missing," check dontallow status or the Local Network settings.

Accessibility permission creates maintenance work

The project warns that macOS ties the Accessibility grant to the app's code signature. After a new build (including one installed via brew upgrade), the signature may change. After an upgrade, run dontallow status. If it reports that the Accessibility grant is missing, remove the old dontallow entry from Accessibility settings and add the path printed by the command.

Once the grant is restored, the agent is expected to reattach itself within ten seconds. The author mentions a future Developer ID-signed release that should remove this extra step, but treat that as "planned improvement," not something you should rely on for the current version. If you update often or manage multiple Macs, factor that maintenance into your decision.

Automation is not a managed policy replacement

For managed Macs, the project says Local Network access can't be pre-set by MDM, though Accessibility can be granted via a PPPC profile. Their suggested fleet workflow is basically: build once, sign the binary with a Developer ID, distribute the binary and profile, then run dontallow install per user.

That's a deployment pattern - not a single macOS switch that centrally denies every Local Network request. IT still needs to evaluate the code, signing identity, user impact, and support process. If a business app depends on device discovery or local access, blanket denial can lead to avoidable help-desk issues. Test with the actual apps and users before rolling it out broadly.