Web browser automation tools stop at the browser. Fazm wires five runtimes into one chat.

The SERP splits cleanly into four buckets. Developer frameworks: Playwright (still the dominant choice, roughly 45 percent of QA adoption in 2026 surveys), Selenium, Puppeteer, Cypress. Low/no-code visual builders: Selenium IDE, Cypress Studio, BrowserStack Low Code, UiPath Studio Web, Power Automate Desktop. AI browser agents: Stagehand, Browserbase, Firecrawl /agent, Multion, Anthropic Computer Use. Consumer browser extensions: Bardeen, Axiom.ai, Ui.Vision. All of them share one structural choice: the automation runtime is the browser. When the workflow needs to leave the browser (open Numbers, paste into Mail, send a WhatsApp), you exit the tool and glue it together yourself.

Fazm is not strictly a web browser automation tool. It is a consumer Mac app in which the browser runtime is one of five parallel automation runtimes wired into the same chat session. The five are named explicitly in the source: `BUILTIN_MCP_NAMES = new Set(["fazm_tools", "playwright", "macos-use", "whatsapp", "google-workspace"])` at `acp-bridge/src/index.ts` line 1266. You can verify this by cloning the repo and grepping. One chat turn can legitimately cross all five runtimes. Every other tool on the SERP ships only the browser runtime.

The official `@playwright/mcp` Node package, pinned inside the app bundle at `acp-bridge/node_modules/@playwright/mcp/cli.js`, resolved at `acp-bridge/src/index.ts` line 47. Playwright MCP is launched with the `--extension` flag (line 1030), which tells it to attach to the user's real Chrome over the Chrome DevTools Protocol through the Playwright MCP Bridge extension rather than launch a fresh Chromium. That gives the browser runtime access to your existing cookies, logged-in sessions, Chrome fingerprint, and 2FA state.

A single line in the bridge source: `const BUILTIN_MCP_NAMES = new Set(["fazm_tools", "playwright", "macos-use", "whatsapp", "google-workspace"]);` at `/Users/matthewdi/fazm/acp-bridge/src/index.ts:1266`. Each name corresponds to a real binary or script bundled with the app: `fazm_tools` is the in-process tool surface (line 1016 registration), `playwright` is the `@playwright/mcp` Node CLI (line 1050), `macos-use` is the Rust binary `Contents/MacOS/mcp-server-macos-use` (line 63, registered at 1059), `whatsapp` is `Contents/MacOS/whatsapp-mcp` (line 64, registered at 1069), `google-workspace` is a Python server under `Contents/Resources/google-workspace-mcp/` (lines 67-69, registered at 1082). All five get announced to the agent in the same session.

Each runtime exposes its tools through the Model Context Protocol (MCP). When the model decides to do something browser-shaped, it emits a `mcp__playwright__browser_*` tool call. When it decides to do something app-shaped, it emits a `mcp__macos-use__*` call. Both return into the same chat session. The bridge at `acp-bridge/src/index.ts` spawns all five MCP servers as child processes in the `getMcpServers()` function (line 977 onward) and multiplexes their tools into a single agent surface. There is no manual glue script. The model picks the right runtime per step.

Sandboxed browser runtimes (fresh Chromium per run, no state carried over) are the right choice for CI test pipelines, public-page scraping, and isolation-critical workflows. Fazm's real-Chrome model is deliberately the opposite tradeoff: it wins on logged-in consumer flows (Stripe dashboard, Gmail, Notion, Figma, etc.) where the account state is the feature, not a bug. If your use case is a reproducible end-to-end test suite, use Playwright or Cypress directly. If your use case is 'do this thing I would otherwise do by hand across my real apps,' that is what Fazm's five-runtime model is for.

Yes. The bridge reads `~/.fazm/mcp-servers.json` at startup (line 1104 of `acp-bridge/src/index.ts`) in the same schema Claude Code uses: `{ "name": { "command": "...", "args": [...], "env": {...}, "enabled": true } }`. Anything you add there shows up alongside the five builtins in the same chat session. Line 1267 classifies each server as builtin or user-defined via the `isUserMcpServer(name)` check, so the UI can distinguish them. This is how users wire in, say, a Linear MCP or a GitHub MCP and have it compose with the browser runtime.

The Rust binary `mcp-server-macos-use` talks to AXUIElement, macOS's native accessibility tree. That returns a structured tree with `[Role] "text" x:N y:N w:W h:H visible` per element, pulled directly from the target app's view hierarchy. Screenshot-based approaches (OmniParser, GPT-4o vision, Anthropic Computer Use in screenshot mode) pay a 500ms to 2s vision inference per step and occasionally click the wrong pixel because the vision model misreads a rendered icon. Accessibility APIs are typically sub-100ms per traversal, return exact coordinates the OS itself uses to compute hit-testing, and never hallucinate elements that are not actually on screen.

Cloudflare Turnstile, Google's 'this browser may not be secure' interstitial on OAuth consent screens, hCaptcha on logged-in admin panels, Akamai Bot Manager on banking sessions, Datadome on e-commerce checkouts. All five look at the fingerprint, session age, and navigator properties of the Chrome making the request. A year-old real Chrome profile that is signed into Google, has your extensions, and has been on that IP for months clears all of them without stealth plugins. A freshly-spun Chromium instance fails most of them out of the box.

Yes. The relevant source files are all in the public repo structure referenced in this page: `Desktop/Sources/BrowserExtensionSetup.swift` (the Chrome extension install flow, token validation), `Desktop/Sources/Chat/ACPBridge.swift` (the Swift-side env var wiring for PLAYWRIGHT_USE_EXTENSION), and `acp-bridge/src/index.ts` (the five-runtime registration, the BUILTIN_MCP_NAMES set, the user MCP config loader). `rg -n 'BUILTIN_MCP_NAMES' acp-bridge/src/index.ts` prints line 1266 verbatim. `rg -n 'mcp-server-macos-use'` prints lines 63 and 1059. Nothing about the five-runtime structure is hand-wavy marketing.

Anthropic Computer Use is screenshot-based and cross-app but cloud-hosted: each step round-trips a PNG to Claude and back. Stagehand is an AI layer on top of Playwright, still sandboxed Chromium, still browser-only. Multion is a browser agent (extension plus cloud planner) that only touches web surfaces. Fazm's differentiator against this cohort is the combination: local execution (no screenshot round-trip), your real Chrome (no sandbox), and the non-browser runtimes. You do not have to pick 'browser agent that is fast but browser-only' vs 'general agent that is slow but cross-app.'

One user message: 'pull yesterday's Stripe payout as a CSV, paste it into a new Numbers sheet titled April 17 Payouts, and DM the summary to @ops in WhatsApp.' The model plans three runtime hops: `mcp__playwright__browser_navigate` to dashboard.stripe.com (real Chrome, already logged in), `mcp__playwright__browser_click` on the export button, then `mcp__macos-use__macos-use_open_application_and_traverse` to open Numbers and paste, then `mcp__whatsapp__whatsapp_send_message` via the bundled WhatsApp MCP. Four tool calls, three runtimes, one chat turn, one app. No glue script, no copy-paste, no Zapier.