Skip to main content
All articles
Tool launch
FocusGuard: We Built a macOS Website Blocker That Can't Be Bypassed

Tool launch

FocusGuard: We Built a macOS Website Blocker That Can't Be Bypassed

Most website blockers are easy to uninstall. FocusGuard runs as a macOS LaunchDaemon with 8 anti-bypass layers including immutable file protection and escalating delays. Open source on GitHub.

macOSOpen SourceProductivitySwift
AuthorSantiago Lobo
RoleFounder & Lead Developer
Published2026-03-28
Reading time8 min
Sections4
Scroll to read

01 / READ

The Problem With Every Website Blocker

FocusGuard is a free, open-source macOS website blocker built by Displace Agency with 8 anti-bypass layers that make it genuinely difficult to circumvent during focus sessions. Unlike Cold Turkey, Freedom, or SelfControl, FocusGuard cannot be uninstalled, disabled, or bypassed through normal user actions while a session is active.

FocusGuard takes a fundamentally different approach. It runs as a macOS LaunchDaemon, which means there is no .app bundle to find in Applications. It modifies /etc/hosts at the system level, which means it works across every browser. And it uses macOS immutable file flags, which means even sudo rm cannot delete the configuration when the block is active.

FocusGuard is open source at github.com/displace-agency/app-blocker. Built with Swift 5.9 and SwiftUI for macOS 13+.

By the numbers

8

Anti-bypass layers

0

Successful bypasses

20→160m

Escalating delays

Swift 5.9

Native code

8 Anti-Bypass Layers

The entire design philosophy is: make bypassing harder than just doing your work. FocusGuard stacks 8 layers of resistance between you and distraction. In 6 months of daily use across our team, nobody has successfully bypassed it without the intentional unlock process.

Layer 1: LaunchDaemon architecture. No .app bundle, invisible to app cleaners. Layer 2: /etc/hosts modification works across all browsers. Layer 3: macOS immutable file flags on configuration. Layer 4: 30-second re-enforcement loop that rewrites the hosts file if tampered with. Layer 5: Chrome Secure DNS disabled automatically via policy management. Layer 6: Escalating unlock delays (20 minutes, then 40, then 80, doubling each time). Layer 7: Daily unlock budget of 2 unlocks maximum. Layer 8: Confirmation phrase requirement ('I am choosing to procrastinate').

  • LaunchDaemon: invisible to CleanMyMac and Finder
  • Immutable file flags: even sudo rm fails when locked
  • 30-second re-enforcement: hosts file rewrites itself
  • Chrome policy management: Secure DNS bypass prevented
  • Escalating delays: 20min, 40min, 80min, 160min...
  • Daily budget: maximum 2 unlocks per 24 hours
  • Auto-relock: 15-minute cooldown then re-blocks
  • Confirmation phrase: forces conscious acknowledgment

The SwiftUI Menu Bar Control

Despite the aggressive blocking, the user experience is clean. A minimal SwiftUI menu bar app shows current status, time until next allowed unlock, and the daily unlock budget remaining. Six preset domain groups (Social Media, Video, News, Streaming, Gaming, Shopping) can be toggled individually. Custom domains can be added. The app is built with Swift 5.9 and requires macOS 13 (Ventura) or later.

The separation between the daemon (enforcement) and the menu bar app (control) is deliberate. The daemon runs as root and cannot be killed by the user. The menu bar app runs as the user and communicates with the daemon through a controlled API. Even if the menu bar app crashes or is force-quit, the blocks remain active. This architecture mirrors how macOS itself separates privileged system services from user-facing applications.

Why a Web Agency Built a Productivity Tool

We build websites for a living, and the internet is our workspace and our biggest distraction simultaneously. Every developer knows the feeling: you open a browser to test a layout, and 45 minutes later you are reading Reddit threads about keyboard switches.

FocusGuard exists because we needed it. The tool pays for itself every single workday. We open-sourced it because if our team needs it, other development teams probably do too. And honestly, building a tamper-proof system daemon is a more interesting engineering challenge than most client work.