Safari-backed MCP outperforms Chromium for macOS browser automation

Every browser-automation MCP server on macOS—chrome-devtools-mcp, playwright-mcp, browsermcp, puppeteer-mcp—defaults to spinning up a fresh Chromium instance with no logins, cookies, or session state. This forces AI agents to spend the first minutes of every task navigating Cloudflare, solving reCAPTCHA, or re-authenticating to Gmail, despite the user already being logged in Safari. The root cause is a silent ecosystem assumption: "just spin up Chromium, it'll be fine." On M1/M2/M3 Macs, this assumption breaks. Each Chromium process spawns multiple helper processes per tab (GPU, renderer, network, storage), duplicates WebKit emulation that Safari provides natively, spikes RAM on tab open, and audibly spins up fans. Headless Chromium appears lighter but remains Chromium—and headless mode is what gets blocked by Cloudflare, reCAPTCHA v3, Akamai, and DataDome, which fingerprint headless browsers within seconds. Running headful Chromium alongside Safari creates a fan-melting two-browser setup.

The author notes this approach only makes sense on macOS—on Linux or Windows, Chromium remains the right default—and sacrifices Chrome DevTools' performance traces and Lighthouse audits, which lack Safari equivalents.

The author built a Safari-backed MCP that drives the browser the user already has open, inheriting logins, cookies, extensions, Apple Pay sessions, and the WebKit process already running. Implementation required solving three hard problems: React's internal `_valueTracker` on controlled inputs silently ignores synthetic "input" events unless the tracker detects a value change—the fix involves calling the native setter via the prototype; shadow DOM traversal requires a recursive walker with MutationObserver caching because `document.querySelector` stops at shadow boundaries and uncached traversal costs 200ms per page; and Content Security Policy blocks `eval` and `Function()`, requiring a four-strategy fallback chain (regular JS → `document.evaluate` → AppleScript `do JavaScript` → injected content script via Safari extension). After months of use, the Safari approach delivered measurably longer battery life, higher agent success rates on authenticated tasks (calendar, banking, booking portals), and non-intrusive background execution via AppleScript and a persistent Swift daemon that doesn't steal window focus. The author notes this approach only makes sense on macOS—on Linux or Windows, Chromium remains the right default—and sacrifices Chrome DevTools' performance traces and Lighthouse audits, which lack Safari equivalents. For the 95% of agent tasks involving navigation, clicking, form filling, data extraction, and screenshots, Safari is worth reconsidering as the default on macOS.

Key facts

1. 01Every major browser-automation MCP (chrome-devtools-mcp, playwright-mcp, browsermcp, puppeteer-mcp) defaults to spinning up a fresh Chromium instance on macOS, forcing agents to re-authenticate despite the user already being logged into Safari