invisible_playwright_mcp Pairs MCP With Stealth Firefox

invisible_playwright_mcp packages a browser agent as an MCP server and a local web UI, while its maintainer claims the underlying Firefox engine is undetected by anti-bot systems and CAPTCHAs. For developers, that means assistant clients can drive page interactions with configuration that may retain login state, route traffic through a proxy and send page content to an external provider. The repository documents each of those behaviors.

Two interfaces to the same browser

The repository provides installation paths for Claude Code, Codex and Gemini CLI. Its standalone interface runs locally, presents chat beside a live browser and requires an OpenRouter key. The same package starts the MCP server when invoked without a subcommand and launches the interface with the ui subcommand. The project also points Python developers to invisible_playwright, a related library whose API follows Playwright’s.

The README says the agent interacts through pointer movements and key presses. Configuration includes proxies, seeded browser identities, persistent profile directories and a headed mode. The project says a repeated seed produces the same browser identity, a profile directory preserves cookies and logins across restarts, and proxy selection determines timezone, locale and network egress. These options are described on the project page.

Analysis: The anti-detection promise is stronger than the evidence presented on the repository page. The claim appears without a target-site matrix, testing protocol, success rate or independent validation. That does not establish that the claim is false, but it leaves developers without a documented basis for estimating reliability against a particular site’s defenses. The repository page presents the claim and configuration details but none of those measurements.

Local execution still has external data flows

The project says the agent runs on the user’s machine and has no server of its own. Sessions, profiles and screenshots are stored locally. However, sites receive browser traffic, the web UI sends its conversation and page content read by the agent to OpenRouter, and an MCP client sends corresponding information to whichever provider it uses. Those boundaries are set out in the project’s privacy policy.

The engine is downloaded from a GitHub release when the server or interface first starts, and a GeoIP database is downloaded when a proxy is configured. Each browser launch also fetches a one-line counter file from a GitHub release. The project says that request carries no identifier, although GitHub sees the originating IP address as it would for another HTTPS request. The maintainer says nothing else is collected or sent to the author.

The README warns that changing the interface host from its loopback default exposes a service with no authentication. It also says passing an OpenRouter key on the command line places the key in shell history and, on Linux, the process list; using an environment variable or local .env file avoids those two exposures. The project documents both warnings.

The unresolved control boundary

Analysis: Pairing persistent browser state with an agent intended to appear less detectable shifts the central deployment question toward authorization and review. A profile can preserve cookies and logins, page data can leave the machine, and a host change can expose an unauthenticated interface. The unresolved trade-off is whether teams can gain useful browser access without granting overly broad access to stored sessions or sensitive page content. Those risks follow from the project’s documented persistence, data-flow and host settings.

The project tells users to read the terms of sites they visit, respect rate limits and avoid submitting anything that a human has not reviewed. Its responsible-use guidance places those obligations on the operator.