A Python automation browser that ships its own Python inside the app so the user never touches pip, venv, or Terminal.

It means an end user can say a sentence in plain English like 'write a Python script that opens Stripe, pulls the last three invoices, and saves them as PDFs,' and Fazm will actually execute it, because Fazm ships its own Python 3.12 interpreter inside the .app bundle and its agent uses that interpreter for any Python work. The alternative, every other library on the first SERP page, is a developer tool that assumes you already have Python on PATH. The Fazm agent's system prompt is literally templated with the absolute path to the bundled interpreter at session start (Desktop/Sources/Chat/ChatPrompts.swift line 21: 'Python: {bundled_python_path} (bundled — never use bare python3/pip3, user may not have Python installed)'), and the path resolves to /Applications/Fazm.app/Contents/Resources/google-workspace-mcp/.venv/bin/python3.

Because the goal is a product that works on first run for a person who has never opened Terminal. Telling a non-developer Mac user to 'install Python' means, in practice, running xcode-select --install, installing Homebrew, installing Python, fixing SSL certificates for certifi, creating a venv, and running pip install. Each of those steps has a well-known failure mode on a clean macOS machine. By bundling a relocatable Python 3.12 built with uv, plus libpython3.12.dylib, plus the full standard library under .venv/lib/python3.12, plus a shell wrapper that sets PYTHONHOME, Fazm turns all of that into a double-click install. The build.sh script handles it at lines 199 to 252.

The Google Workspace MCP server. It is a Python project launched by acp-bridge/src/index.ts line 1076 with 'command: googleWorkspaceMcpPython' and 'args: [googleWorkspaceMcpMain, --transport, stdio]'. It exposes Gmail, Calendar, Drive, and Docs as MCP tools. Any future Python MCP server the user adds (from ~/.fazm/mcp-servers.json) is also expected to use the bundled interpreter's path, because the agent is told at startup that bare python3 is not available. The browser itself is driven by the TypeScript-based Playwright MCP, but the two servers coordinate inside one user turn, so 'Python' and 'browser' are both happening in a single conversation.

Hermetic by design. The wrapper scripts at .venv/bin/python3 and .venv/bin/python3.12 (build.sh lines 227 to 233) compute VENV_DIR from their own location and export PYTHONHOME before exec'ing the real CPython binary. That means stdlib resolution is always relative to the app bundle. pyvenv.cfg is rewritten to 'home = bin' (build.sh line 244) so site-packages is pinned to the bundle. And 'include-system-site-packages = false' in the same pyvenv.cfg means your ~/.pyenv or /opt/homebrew/bin/python is never consulted. Your Python installation, if any, is not touched.

Because macOS code-signs the app bundle, and Sparkle (the auto-update framework) verifies that signature before applying updates. If Python writes .pyc files into the bundle's site-packages on first import, the bundle's on-disk state diverges from the signed state and Sparkle refuses to update. The fix is one env var: acp-bridge/src/index.ts line 1092 sets PYTHONDONTWRITEBYTECODE=1 on the server's environment. Python loads .py files, never writes .pyc back, and the signature stays valid.

Two differences. First, the browser Fazm drives is your real running Chrome, attached over CDP through the Playwright MCP Bridge Chrome Web Store extension (ID mmlmfjhmonkocbjadbfplnigmagldckm), not a fresh Chromium downloaded into ~/.cache/ms-playwright. That means your existing cookies, 2FA state, WebAuthn credentials, and Cloudflare session are all live on turn one. Second, the agent reads an accessibility snapshot returned by browser_snapshot (labelled DOM nodes with [ref=eN] tokens), not CSS selectors you wrote or screenshots a vision model has to guess coordinates from. Neither difference has anything to do with Python as a language; they are consequences of Fazm being an AI-driven product rather than a script runner.

Any Mac app, through the bundled macos-use MCP server (acp-bridge/src/index.ts line 1059). macos-use reads AXUIElement trees from the macOS Accessibility APIs, which is the same machinery VoiceOver uses. That means Fazm can drive Finder, Settings, Mail, Notes, Figma, Xcode, and any native or Catalyst Mac app, not just a browser tab. The browser is one MCP server among five; the other four are fazm_tools, macos-use, whatsapp, and google-workspace. In a typical session, the agent chains calls across all of them inside a single user turn.

Options in order of preference. One, the agent can run the user's command with a one-off 'uv run --with package' if the user has uv installed. Two, the user can add a local MCP server config at ~/.fazm/mcp-servers.json pointing at their own Python venv; the bridge loads that file at startup (acp-bridge/src/index.ts line 1104) and spawns their server alongside the bundled ones. Three, the specific case of 'I want to use telethon' is covered by the Telegram bundled skill (Desktop/Sources/BundledSkills/telegram.skill.md), which is taught to the agent as a preferred path over browser automation for that one service.

Roughly 400 MB including every bundled MCP server, the Node runtime for acp-bridge, the Swift UI binary, Playwright's Chromium-less install (because Fazm uses your real Chrome, Playwright MCP does not ship its own browser), and the Python 3.12 interpreter plus stdlib plus google-workspace-mcp dependencies. The Python payload itself is on the order of 100 to 150 MB of that, dominated by the stdlib copy at .venv/lib/python3.12 (rsynced in at build.sh line 241) and the libpython3.12.dylib copied in at line 237.

No, on purpose. The system prompt instructs the agent to never use bare python3 or pip3 regardless of what the user has installed, because the agent cannot reliably know whether the user's Python is a working version. The bundled interpreter has the known-good stdlib and the known-good set of dependencies the Fazm MCP servers need. Using the system Python would also risk writing .pyc files outside the app bundle and hitting a user's venv that has different dependency pins.

Yes. CPython is distributed under the PSF license, which is MIT-compatible and permits redistribution in a commercial product. The relocatable venv is produced by uv, which is Apache 2.0 licensed. libpython3.12.dylib is signed as part of the app bundle during the build because it is copied into the app bundle and then codesigned with the rest of Contents/Resources. PYTHONDONTWRITEBYTECODE=1 preserves the signature at runtime. The path the agent is told to use sits inside Contents/Resources, which is where Apple expects third-party payloads to live.

Only if they are in the Google Workspace MCP's pyproject.toml dependency list at build time. build.sh line 211 reads pyproject.toml with tomllib and passes its dependencies to 'uv pip install'. The project currently ships MCP, google-auth, google-api-python-client, and the libraries those pull in. For a Python MCP server that wants pandas, the user adds it as a user MCP at ~/.fazm/mcp-servers.json with the command pointing at their own venv's python, and the bundled Python stays untouched. That separation is deliberate: the bundled Python is a product surface, not a general-purpose user-facing REPL.