How to Connect Gemini CLI to Chrome DevTools MCP

Can Gemini CLI control a Chrome page?

If your Gemini CLI account is still eligible, yes. Current docs describe an experimental built-in Browser Agent backed by bundled Chrome DevTools MCP, and a separate MCP server remains configurable. Check which Chrome profile or session each route uses before opening a page. Gemini account access and browser login are separate. Google’s consumer-access cutoff has passed for some plans, so verify your entitlement first. One user reported that an older Gemini CLI installation could not connect to the DevTools MCP server even though another client could. That case shows where to start diagnosing a failed connection. GitHub #178

If your Gemini CLI account is still eligible, yes. Current docs describe an experimental built-in Browser Agent backed by a bundled Chrome DevTools MCP, and a separate MCP server remains configurable. Check which Chrome profile or session each route uses before opening a page. Gemini account access and browser login are separate. Google’s consumer-access cutoff has passed for some plans, so verify your entitlement first. If you see Connected from gemini mcp list, check a real page before concluding the setup works. One user reported that an older Gemini CLI installation could not connect to the DevTools MCP server even though another client could. That case shows where to start diagnosing a failed connection. GitHub #178

The browser version of Gemini is a separate interface. Gemini CLI also lists Chrome DevTools MCP in its extension directory. A project settings file lets you record the server version, tools and launch options alongside the project. Gemini CLI MCP guide Chrome DevTools agent setup

Google's lifecycle announcement changes which Gemini CLI users can rely on the old setup. As of 2026-11-09, its June 18, 2026 service cutoff for Google AI Pro/Ultra and free Gemini Code Assist for individuals has passed. Google says Standard and Enterprise customers and users with paid Gemini or Gemini Enterprise Agent Platform API keys retain Gemini CLI access. Check your own entitlement before following this guide. The Gemini CLI browser docs and MCP configuration remain available for eligible users. Google's transition notice Gemini CLI migration guide

Key takeaways

• Register Chrome DevTools MCP in the project and start with an isolated Chrome profile.

• Use gemini mcp list to check the connection and /mcp desc inside Gemini CLI to inspect available tools.

• Run one small browser task and verify its final URL and heading against the tool result.

• Treat Gemini authentication, workspace trust, and approval for MCP tools as separate checks.

• Keep the first task to opening and reading a page you are allowed to inspect.

Search and browser control answer different questions

A search result can point you to a release announcement. It cannot identify which account a browser tab is using or show the state after a click. Conversely, a snapshot can confirm a page's title without telling you whether it is the current official source. Start with the question, then pick a tool that can return an observable result. See how web search differs from browser control and what an AI agent does.

Pin the CLI and server in a small project

The commands below are a configuration example based on the official docs. They pin Gemini CLI 0.67.0 and Chrome DevTools MCP 1.12.0 so the tool schema is identifiable. Check the server’s Node.js and Chrome prerequisites for your platform and keep the package lockfile. Chrome DevTools MCP v1.12.0

mkdir browser-mcp-check
cd browser-mcp-check
npm init -y
npm install --save-exact @google/gemini-cli@0.67.0 chrome-devtools-mcp@1.12.0
./node_modules/.bin/gemini --version
./node_modules/.bin/chrome-devtools-mcp --version

In that test project, add the following server entry to .gemini/settings.json. Replace the command with the absolute path to the project-local binary. If the file already contains settings, merge the new server entry instead of replacing the whole file.

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "/absolute/path/browser-mcp-check/node_modules/.bin/chrome-devtools-mcp",
      "args": ["--headless", "--isolated", "--no-usage-statistics"],
      "includeTools": ["new_page", "take_snapshot", "list_pages", "close_page"],
      "trust": false
    }
  }
}

includeTools is a client tool filter. It does not limit the sites Chrome can reach. Start with a page you control or are permitted to inspect, and keep the isolated profile free of personal accounts. The --isolated option starts a temporary Chrome profile. If you later need an existing session, set that up separately and confirm the account before reading private data. See how agents connect to an existing browser.

Google's Codelab uses a larger UI test application. A small page is easier for checking startup because you already know what its title and key link should be. After the first run, you can add a click or a console check if your test actually needs it. Google's agentic UI testing Codelab

Workspace trust lets Gemini load the project configuration. The server’s trust: false leaves tool calls subject to the active policy. Start interactively so you can review the server name, action and URL if Gemini asks for approval. An ask_user rule denies the call in non-interactive mode. If the environment needs a URL allowlist, configure it separately in Chrome DevTools MCP. The server’s --allowed-url-pattern option requires Chrome 149 or later. Gemini CLI policy Chrome DevTools MCP configuration

Verify the connection, then the actual page

From the project folder, run ./node_modules/.bin/gemini mcp list. If the workspace is trusted, its project settings can supply the local server configuration. Start Gemini CLI interactively and use /mcp desc to inspect the exposed tools and their parameters. Set up model access separately with one of the supported authentication methods.

For a repeatable check, serve a small local fixture from a second terminal. Run these commands in the test project. The expected heading is “MCP browser check” and the expected link points to #details. Use the output of the tool to check both.

mkdir -p fixture
cat > fixture/index.html <<'HTML'
<!doctype html>
<meta charset="utf-8">
<title>MCP browser check</title>
<h1>MCP browser check</h1>
<a href="#details">Details</a>
<p id="details">Local fixture</p>
HTML
python3 -m http.server 8765 --bind 127.0.0.1 --directory fixture

In the pinned server version, pass the ID returned by new_page as pageId to take_snapshot. The URL can change after a redirect. Inspect the final URL and heading before deciding the check passed. Tool reference for v1.12.0

Use the chrome-devtools MCP server to open http://127.0.0.1:8765/. Return the page ID, final URL, main heading and one expected link. Take a snapshot of the returned page ID. If the browser cannot reach the page, report the tool error. Do not enter credentials, submit a form or modify anything.

Native Browser Agent or the existing MCP setup?

Current Gemini CLI documentation describes an experimental browser_agent that uses a bundled Chrome DevTools MCP server. It is disabled by default, needs Chrome 144 or later, and asks for one-time consent. Its persistent mode uses a Gemini CLI profile; isolated creates a temporary one; existing attaches to a running Chrome after remote debugging is enabled. That is a newer route than installing the separate server below, but it is still a Chrome route and does not automatically select your Tabbit profile. Check the Browser Agent guide and current release notes.

Use Tabbit CLI for a signed-in Tabbit browser on the same machine

If the Gemini CLI process runs on the machine with Tabbit, its Agent Skills discovery can include the user's ~/.agents/skills/ directory. Check with /skills list, then ask Gemini CLI to activate the Tabbit skill and approve its access when prompted. This only confirms the skill is discoverable. The CLI process must also be allowed to run the local Tabbit launcher, and that launcher must reach the Tabbit instance whose target site is already signed in. These are separate checks. A remote Gemini CLI process cannot reach a desktop's Tabbit runtime unless a supported local handoff is configured. Gemini CLI skill discovery Tabbit CLI setup

For example, ask Gemini CLI to read one public release-note page and save a reviewable draft. This task prompt does not rely on a Gemini-specific /tabbit command:

Use the installed Tabbit skill and Tabbit CLI from this local Gemini CLI session. Open the release-notes page in a separate task tab. Read the current version's visible date and feature entries only. Return a draft named "Release notes review — draft 01" with version, date, feature, source URL, and one item that needs human confirmation. Do not edit the source page or publish the draft. Show me the draft and source links for review. If the skill is missing, the shell cannot run the Tabbit launcher, or the page is signed out, say which check failed and stop.

A separate task tab lets you continue using the ordinary Tabbit window. Tabbit CLI reuse of a signed-in browser session was verified in a local fixture in this environment. That test did not run through Gemini CLI and does not prove a Gemini-to-Tabbit integration. Use this route only after checking the actual local runtime and account. For migration instructions, use the Antigravity CLI guide; its browser feature is separate from the Tabbit CLI route.

Locate failures before changing settings

When the server connects but a browser action is slow, check which executable actually ran. A user on an Apple Silicon Mac reported that an Intel Node installation was on the path used to launch MCP. Correcting their PATH solved their own slowdown. Treat that as a diagnostic clue for that setup. Check the architecture before changing Node, Chrome or the model. Original r/mcp report

If new_page succeeds and the snapshot fails, inspect the tool schema and arguments. In a browser with multiple tabs, take the ID from the tool response. If the resulting URL or heading points to a sign-in page, report the handoff. Keep the task read-only until the right session and record can be verified. See checking a signed-in session for an example of that distinction in another client.

Keep a short receipt you can rerun

Save the two package versions, browser version, server scope, browser mode, allowed tools, final URL, page ID and expected result. Record any approval or failure at the step where it happened. Use the first browser-agent task checklist to decide what belongs in the record. If you need to choose between a fresh profile and an existing session, see how browser connections differ. For tasks that start with the tabs you already have open, the agentic browser guide explains the browser-first approach.

For a project that needs live Chrome state in a Gemini CLI session, start with the project-scoped server and a single known page. Once you can verify that result, keep the same evidence requirements when you add the next tool.

Secholar.L

Growth & Content at Tabbit

Secholar.L writes hands-on guides about AI browsers and agent workflows, comparing tools with real research and citing verifiable sources.