Apple's macOS Sequoia introduced a Local Network permission prompt meant to give users control over which apps discover devices on their LAN. The design intention was sound: ask once, remember the answer. In practice, the system is broken for a significant class of apps, and there is no supported way to fix it. The core failure is path-based keying. macOS ties the Local Network decision to the app's file path. Chromium-based browsers — Chrome, Brave, Edge, Arc, Island — copy their own bundles into randomized temp directories on every launch to survive in-place updates. Each launch looks like a brand-new app to the OS. The result: duplicate rows pile up in Privacy settings, each pointing to a path that no longer exists. Apps with versioned install paths trigger a new permission row per update. Some prompts are misattributed entirely, appearing for apps that aren't even running. There is no MDM payload to pre-deny the permission. The tccutil reset command doesn't cover it. System Settings offers no way to prune orphaned entries. For enterprise fleet managers, this is a dead end: Local Network is the one privacy permission that cannot be pre-configured. The permission system exists, but the management surface does not. dontallow is a 200-line Swift agent that registers an Accessibility observer on the system's UserNotificationCenter process, waits for window-creation events, reads dialog text to confirm it's a Local Network prompt, and presses Don't Allow. It never modifies system files, never chooses Allow, and sleeps at zero CPU between events. It ships as two Swift files with no dependencies, installs via Homebrew or make, and writes a launchd agent that survives reboots. The tool includes practical escape hatches: a configurable allowlist for apps that genuinely need LAN access (Chromecast, AirPlay, LAN gaming), a pause command with duration, and a grace period setting. Each dismissal posts a macOS notification naming the app and the pause command. For managed fleets, the binary can be signed with a Developer ID and deployed with a PPPC profile granting Accessibility — the one manual step that can be automated. The deeper story is about Apple's permission-prompt model hitting its limits. The Local Network prompt was designed for a world where app identity is stable and paths are predictable. Chromium's update strategy — which is itself a reasonable engineering choice — breaks that assumption completely. Rather than fix the keying mechanism or provide administrative tools, Apple has left a gap that an open-source project now fills with an accessibility hack. The workaround requires granting Accessibility permission — itself a powerful entitlement — to dismiss a prompt that shouldn't be recurring in the first place. This is a small tool solving a real problem, but it's also a signal. When a platform's permission UX is so broken that power users build automation to dismiss it, the permission system has stopped serving its stated purpose. The friction isn't protecting anyone; it's training users to ignore security prompts reflexively — exactly the outcome the prompt was designed to prevent.
