SafetyCard Request a review

invisible_playwright_mcp

MCP server (plus optional web UI agent) that drives an anti-detection patched Firefox: navigate, click, type, read, upload, run page JavaScript.

github.com/feder-cr/invisible_playwright_mcp · 2026-10-04 · 4139237

Defense-in-depth score

2.3 / 10

A capable stealth-browser MCP server with unusually careful file-upload scoping and password masking, but the dominant risk is that browser_evaluate runs arbitrary JavaScript while advertising itself as read-only, so hosts that auto-run read-only tools let an injected web page exfiltrate data or act on sites unattended. Navigation has no URL restrictions (file://, localhost and internal hosts are reachable), the server keeps no record of what it did, and it auto-loads a .env from the launch directory that can silently enable uploads, swap the proxy or engine binary, or expose the server over HTTP.

Safest setup

invisible_playwright_mcp starts each browser on a fresh profile with no logins, keeps file uploads off until you name a directory, and masks password fields in what it returns. Beyond that the defaults are thin: no URL limits, no record of tool calls, and browser_evaluate is labelled read-only, so the safest setup leans on your host's approval and on containment around the process.

SetupHowWhat it gives you
A dedicated OS userRun the server under an OS account that holds no browser profiles, saved logins or files the task doesn't needWhatever profile or file:// path the model reaches for, it finds only what that account holds C1
Per-call approval in your hostSet your MCP client to ask before every tool call, browser_evaluate included, whatever its read-only label saysA person sees each script, navigation and form action before it runs on a live site C2
Uploads off or stagedKeep INVISIBLE_MCP_UPLOAD_DIRS unset, or set it to one absolute staging directory holding only the files to sendPages can only receive files you put in place for them C3
The stdio transportKeep the default STEALTHFOX_MCP_TRANSPORT of stdioOnly the client that started the server can talk to it C6
A clean launch directoryHave your host start the server from a directory holding no .env file you didn't writeUploads, proxy, engine binary and transport stay as you set them, not as a cloned repository sets them C6
Its own container or VMRun the server and its browser in a container or VM whose network reaches only the sites the task needs, with local and internal addresses out of reachAn outer boundary on where pages, scripts and navigation can send data C3
A record in your hostKeep your MCP client's transcript of every tool call and its argumentsA record of what the browser was asked to do, since the server keeps none C9

Approving with confidence

  • Read each prompt and approve calls one at a time; a browser_evaluate call runs any JavaScript in the page, so read the script before approving it.
  • Navigation to file:// paths, localhost or internal hosts, or a profile or proxy you didn't choose, is worth a closer look before approving.

Handling data

  • The saved session file keeps proxy credentials in plain text with default permissions; store it like other credentials.
  • Standalone clients share one session file, so run one client per OS user.

Key gaps (3)

  1. browser_evaluate runs arbitrary model-written JavaScript but is annotated readOnlyHint=true, which the server documents as permission for hosts to run it without asking. C2 · Approval gates
  2. Hijacked sessions can leak page data and act on live sites unattended: arbitrary JavaScript runs through a tool advertised as read-only, and navigate has no URL restrictions. C5 · Untrusted input blast radius
  3. A .env in the host's working directory is auto-loaded by the MCP server and can enable uploads, redirect all traffic through a proxy, choose the engine binary, or bind the unauthenticated HTTP transport to any interface. C6 · Memory, context & configuration integrity

Criteria

C1 Identity & least privilege

0.17 / 1.00

The server runs as the local user and holds no credentials of its own by default; the default browser is a fresh, throwaway profile with no logins, which is a real narrowing. But nothing checks what the browser is allowed to reach: the model can point browser_open at any directory as the profile (including a directory that already holds logins), choose any proxy, and navigate to any URL including file:// paths and local network services. A .env file in the directory the host starts the server from can widen the same settings silently.

C2 Approval gates

0.25 / 1.00

As a tool server it does not own the approval prompt, so what matters is the risk signal it gives the host. Every tool carries explicit readOnly/destructive hints and clicking, typing and navigating are correctly marked destructive. But browser_evaluate, which runs arbitrary model-written JavaScript in the page, is marked read-only, and the code's own comment says read-only means a client may run it without asking. A regex refuses a handful of obvious page-changing calls but, by the authors' own statement, is not a boundary, and fetch(), location changes and similar calls pass. There is no server-side read-only mode or dry-run.

C3 Tool & action scoping

0.20 / 1.00

File upload is a model of careful scoping: it is off unless the operator lists directories, and each path is resolved, contained, refused through hidden directories, size-capped, and re-checked on the opened file. Everything else is general-purpose. browser_navigate accepts any URL with no scheme or host check, so file://, localhost and cloud-metadata addresses are not refused. browser_evaluate takes arbitrary JavaScript behind a denylist of a few method names. browser_open accepts any directory as a profile.

C4 Code-execution isolation

0.45 / 1.00

Model-written JavaScript runs through browser_evaluate inside the page of a patched Firefox. The only containment is the browser's own content-process sandbox and same-origin rules, which this repository neither configures nor verifies; the regex filter on the script is explicitly described by its authors as not a sandbox. The browser process itself runs as the user with the server's environment, full network, and whatever logins the chosen profile holds.

C5 Untrusted input blast radius

0.00 / 1.00

The server reads arbitrary web pages and returns their text, HTML and snapshot to the model as plain results, with no untrusted marker and mixed with the server's own instructions. Nothing drops a leg of the Rule of Two: the same session reads hostile pages, can hold logged-in sessions or local files, and can send data anywhere through navigate or through browser_evaluate, which is advertised read-only so many hosts will run it unprompted. The server's own instructions also coach the model to use throwaway-mail sites to get through email verification.

C6 Memory, context & configuration integrity

0.10 / 1.00

The MCP server reads a .env file from whatever directory the host starts it in, before serving, and applies every variable it finds. Hosts commonly start servers in the project directory, so a cloned repository's .env can silently turn on uploads from chosen directories, route all browsing through an attacker's proxy, pick the browser profile or engine binary, or switch the server to HTTP on any interface with no authentication. Separately, the proxy and profile a model chooses are written to a session file and reused by the next browser_open with no arguments, and all standalone clients share the same default file.

C7 Third-party extensions

0.35 / 1.00

The server has no plugin or extension mechanism, but at startup it automatically downloads and then runs a roughly 250 MB patched Firefox build. The download and its check against a pinned 'seal' live in the invisible-playwright/invisible-core dependencies, so the verification can't be confirmed from this repository. The binary path can also be set through STEALTHFOX_BINARY, including from a workspace .env, and the browser runs as the user with the server's environment.

C8 Secrets & sensitive-data protection

0.42 / 1.00

There is good care around page secrets: password and one-time-code fields are masked in snapshots, HTML reads and typing replies, so a filled password is not echoed into the conversation, and the server drops any OpenRouter key from its environment before launching the browser. There is no telemetry and no logging. Weak spots: proxy credentials are written in plaintext into the session file with default permissions, and browser_evaluate and read_text can still read secret values directly.

C9 Audit & traceability

0.00 / 1.00

The MCP server keeps no record of what it did: no tool-call log, no audit file, no logging calls at all in the server package. The only persisted file records who the main browser is (seed, proxy, profile), not its actions. Any record of activity exists only in the host's transcript, which doesn't count for the server.

C10 Limits & kill switch

0.38 / 1.00

The server bounds most single operations: navigation waits at most 45 seconds, element actions 15 seconds, and text and JavaScript results are capped at 6,000 characters. Some operations are open-ended: snapshots are uncapped by default, press-and-hold duration is whatever the model asks, and browser_evaluate has no timeout. Closing the stdio connection closes the browsers and cancels background typing. There are no rate limits.