A macOS AI code agent that does not stop at the editor

A process that runs natively on macOS, holds a model in a loop, and is allowed to read and write your files, run your shell commands, and (depending on the tool) operate the rest of your machine. Cursor, Claude Code CLI, OpenAI Codex CLI, Cline, and Aider are all in this category. They differ on where the loop runs (editor process, terminal subprocess, hosted runner), what its access surface is (just the project tree, or the whole laptop), and which model it ships with by default.

A copilot writes inline suggestions and waits for you to accept them. An agent runs an autonomous loop: it picks the next tool call, runs it, reads the result, decides what to do next, and only stops when the goal is met or it hits a budget. The 'agent' word in macOS AI code agent is specifically claiming that loop, not just autocomplete. Whether the loop is worth handing the keys to is a separate question, and the answer mostly depends on the access surface, not the model.

Two reasons. First, latency: every tool call that crosses a network adds round-trip cost on top of the model token cost, and code work fires a lot of small tool calls. Second, access: a hosted sandbox, by construction, cannot read your real Chrome session, your local Mac apps, your menubar, your dotfiles, or anything outside the cloned repo. A locally running agent can. Whether you want it to is a different question, but the option only exists for the local one.

A CLI or editor coding agent's access surface is the project tree, the shell, and (sometimes) a sandboxed browser. A Mac-native shipped-app agent that wires accessibility APIs can additionally read and operate any Mac app the way a person does: Xcode build errors, Linear desktop tickets, Slack threads, the Vercel deploy status in your real browser, the failing GitHub Action you have open in another tab. In Fazm's case the agent process spawns five MCP servers by default, including playwright (your real Chrome session) and macos-use (the native accessibility binary). Re-check the line: acp-bridge/src/index.ts:1823, the constant is BUILTIN_MCP_NAMES = new Set(["fazm_tools", "playwright", "macos-use", "whatsapp", "google-workspace"]).

Fazm spawns @agentclientprotocol/claude-agent-acp as a Node subprocess (acp-bridge/src/index.ts:855), so the default coding model is Claude Sonnet 4.6 (the DEFAULT_MODEL constant at line 1802). It also spawns a separate Codex provider (codex-provider.ts) when the user picks any model whose id matches CODEX_MODEL_PATTERN = /^(gpt-|codex-|o[0-9]-?)/i (codex-query.ts:61). For routing through a different gateway, set Custom API Endpoint in Settings; the bridge passes it through as ANTHROPIC_BASE_URL into the spawned process. Anything that speaks the Anthropic Messages API works: corporate proxies, GitHub Copilot's Anthropic-compatible bridge, a small translator in front of Ollama or LM Studio.

Open. The bridge is at github.com/m13v/fazm under acp-bridge/src/index.ts, MIT-licensed. The line numbers cited above (855 for the spawn, 1512 for buildMcpServers, 1802 for DEFAULT_MODEL, 1823 for BUILTIN_MCP_NAMES) all resolve in that file. The macOS-use accessibility binary lives in github.com/browser-use/macOS-use and is bundled into the app bundle under Contents/MacOS/mcp-server-macos-use. No claim above is true unless those files say so.

Claude Code CLI is a terminal program. Its access surface is your shell, your file system, and a fixed set of MCP servers you configure in ~/.claude/mcp_servers.json. Fazm wraps the same Claude Agent SDK loop (the patched ACP entry at acp-bridge/src/patched-acp-entry.mjs imports ClaudeAcpAgent from @agentclientprotocol/claude-agent-acp) and ships it inside a Mac app, with five MCP servers pre-wired and an extra path through Codex. The interesting difference is not the model, the model is the same. It is that the agent process is now spawned by a desktop app whose other tools (browser overlay, accessibility daemon, Whisper-based voice input) are sitting right next to it in the same address space, so the agent can use them without you wiring them up.

Sometimes. Voice is right when the prompt is long-form ("add a Stripe webhook handler that retries on 5xx, has a 30s idempotency window, and writes to the existing fazm_emails table") and your hands are on the keyboard for editing the response. It is wrong for short tight loops where typing is faster (a one-line refactor). The honest answer is that voice-first is a meaningful upgrade for agent prompts, which tend to be a paragraph long, and a wash or worse for individual code edits. Plenty of users keep the chat window open and only press the voice button when they have something paragraph-shaped to say.

Correct, and worth thinking through before you run one. Three controls help. First, every Fazm tool call is logged to /tmp/fazm.log (or fazm-dev.log in dev) before it executes, so a tail -f at startup is enough to see everything. Second, browser pages get a visible 'Browser controlled by Fazm' overlay injected at runtime; the loud failure mode is in acp-bridge/src/index.ts around lines 1574 to 1597. Third, you can run with FAZM_OBSERVER=true and the agent gets only the fazm_tools server, no browser, no accessibility, no Whatsapp, no Workspace (line 1543). Use observer mode when you want the loop without the keys.