Browser testing automation that does not stop at the edge of the tab

Selenium, Cypress, and a Playwright script are all sandboxed to the browser viewport. The moment a flow hits a native file dialog, a Keychain unlock, a 1Password quick-access popup, or a desktop Slack notification, they are blind. Fazm is not a library you import; it is a signed Mac app whose agent runtime registers five built-in MCP servers per session (fazm_tools, playwright, macos-use, whatsapp, google-workspace) at acp-bridge/src/index.ts line 1266. Two of them, playwright and macos-use, both expose an aria-style accessibility tree. So the same agent turn that clicks 'Upload' inside the browser can also click 'Choose' inside the macOS file dialog one millisecond later, and it sees both as structured role trees, not pixels.

In acp-bridge/src/index.ts, the function buildMcpServers (line 992) is called for every ACP session. Starting at line 1027 it pushes the Playwright MCP server with the exact flags --output-mode file --image-responses omit --output-dir /tmp/playwright-mcp on line 1033. Then at line 1057, if the macosUseBinary exists on disk, it pushes a second MCP server named macos-use which runs a native binary that speaks macOS AXUIElement directly. Both servers are live for the whole session. The agent picks which one to call based on what the proposed step looks like: page-level means Playwright, OS-level means macos-use.

Because any check that compares pixels is, by construction, flaky. The three flags on line 1033 (--output-mode file, --image-responses omit, --output-dir /tmp/playwright-mcp) cooperate to make the Playwright MCP server write its aria snapshots to YAML files on disk and strip inline base64 screenshots from the model context. That forces the agent to pick its next click against a stable structural tree (role + accessible name + ref=eN) instead of an image. Re-runs on the same page pick the same refs. Scrolling, theme flips, banner shifts, and 1 px layout jitter do not change role trees, so they do not change test outcomes.

Via a Chrome Web Store extension with the literal id mmlmfjhmonkocbjadbfplnigmagldckm (Desktop/Sources/BrowserExtensionSetup.swift line 678). When the environment variable PLAYWRIGHT_USE_EXTENSION is set to true, acp-bridge/src/index.ts lines 1029 to 1031 append --extension to the Playwright CLI args, which tells Playwright MCP to attach to the running Chrome session rather than launching its own. That means the tests run against your actual logged-in cookies, real 2FA state, and real extensions. A test that says 'check my Gmail inbox for the verification code' can just work, because the cookie is there.

Take a typical broken flow: 'upload a CSV on the admin dashboard, verify that the generated PDF landed in ~/Downloads, then check Slack for the success notification'. Browser testing automation tools handle step one and give up on two and three. Fazm handles all three: Playwright MCP clicks the visible Upload button in the dashboard, the OS file picker opens, macos-use takes over and navigates Finder to the CSV, Playwright watches for the in-page toast, then macos-use opens Finder again, confirms the PDF exists in ~/Downloads, and finally opens the Slack desktop app to read the latest notification in the target channel. Same agent, same aria idiom, different MCP servers.

It is a product. Fazm is a signed Mac app you download from fazm.ai and double-click. There is no npm install, no driver binary to keep in sync with Chrome, no test runner to configure, no CI hookup required. You describe the check in plain English, the agent picks from its five MCP servers, and every proposed step is resolved against an accessibility tree. That is the tradeoff: the cycle time of typing English beats writing code, but you are not building a frozen regression suite for CI. If you need 500 deterministic tests on every pull request, keep Playwright in CI and use Fazm for the flows a script cannot reach.

Several. One: the test flow requires an OS-level permission prompt (Screen Recording, Microphone, Full Disk Access) that cannot be dismissed from the browser. Two: the flow redirects to a native SSO prompt hosted by Keychain or 1Password. Three: the flow depends on an attachment actually existing on disk after download, and the browser runner has no filesystem checker. Four: the flow posts to desktop Slack via a native notification, and the assertion is 'did the notification actually arrive'. Five: any flow where the real browser extension ecosystem matters (ad blocker, password manager, MCP bridge). Fazm catches all five because macos-use talks to the real macOS accessibility tree, not a headless sandbox.

They land in /tmp/playwright-mcp as YAML files. Each file is a full role tree snapshot of the page at the moment the agent captured it, with ref=eN identifiers on every element. After a session, you can cd /tmp/playwright-mcp and open the files directly to see exactly which roles the agent reasoned against. That is the closest thing to a deterministic replay log without instrumenting your own page. Native macOS accessibility traversals from macos-use are logged the same way, as .txt files in /tmp/macos-use/, each with a timestamped screenshot alongside for visual verification.

In the one you are watching. Once the Chrome extension is connected, Playwright MCP attaches to your real running Chrome. Fazm injects a visible overlay (a full-viewport div with id 'fazm-overlay' at z-index 2147483647, defined in acp-bridge/browser-overlay-init.js) with a centered pill reading 'Browser controlled by Fazm'. The overlay uses pointer-events:none, so you can still click, switch tabs, and keep working while the agent operates. Every page it touches gets this overlay so you can always tell whether the agent has control.

Yes, and you probably should. The two modes solve different problems. Playwright in CI gives you frozen, deterministic regression on every pull request. Fazm on your Mac gives you a way to check a real end-to-end flow against your actual signed-in sessions, today, across both the browser and the rest of the desktop. If your production automation contract is 'ship with green CI', keep Playwright. If you also need 'verify this cross-app flow really works on my machine before I ship', Fazm complements it. They do not replace each other.

Only for verification, never for targeting. macos-use targets elements from the accessibility tree output, which is stored as a plain .txt file per traversal. Each element has role, title, and explicit x, y, w, h coordinates read from the AX tree itself. Clicks are auto-centered at (x+w/2, y+h/2). A screenshot is saved alongside only so a human (or the agent) can visually double-check that the action had the intended effect. Targeting is still structural; the screenshot is a sanity check, not a selector.

A Mac, Google Chrome, the signed Fazm app, and Accessibility permission granted in System Settings. At first launch the app runs a three-stage Accessibility self-test (testAccessibilityPermission in Desktop/Sources/AppState.swift) to confirm the runtime is alive before the agent attempts any work, then opens the Playwright MCP Bridge onboarding window to install the Chrome extension with id mmlmfjhmonkocbjadbfplnigmagldckm. After that, no drivers, no PATH edits, no test runner config. The agent uses whichever MCP server the step needs, per turn.