Letting Claude Drive Your Browser with Claude in Chrome — Setup and Caveats After the Paid-Plan Rollout
Claude in Chrome is a Chrome extension that runs Claude in the browser side panel, lets it see the current tab, and lets it click, type, fill forms, navigate, and shuttle information between tabs on your behalf. When it debuted in August 2025 as a Max-only research preview, access was capped at about 1,000 users. The current Chrome Web Store listing shows availability on every paid plan as of February 2026.
My day-to-day already leans heavily on Claude Code and Codex from the terminal, and any browser automation I needed I would reach for Playwright MCP. Since installing Claude in Chrome, that positioning has shifted: a real slice of my day-to-day work that requires the browser (especially anything happening on a post-login web page) now goes to Claude by default. This post is what I have learned running it as a daily driver, ordered as: setup, tasks that actually work, tasks that go wrong, the permission model, and where it sits relative to the alternatives.
What Claude in Chrome Is
The extension surfaces a Claude chat UI in Chrome’s right side panel and feeds that Claude the visible DOM of the current tab, plus the contents of any other tabs you drop into its tab group. You type instructions in natural language, and Claude translates them into concrete DOM operations: click, input, scroll, URL navigation, tab switches.
The product page frames the target use cases roughly as:
- Reading and summarizing analytics dashboards
- Organizing files in Google Drive
- Preparing for calendar events
- Competitor research across multiple tabs
- CRM entry and inbox triage
- Interacting with internal admin panels, legacy portals, and invoice systems
The last three (admin panels, legacy portals, invoice systems) are where Anthropic is putting the emphasis when they compare against other automation tools. This is the class of work that would not justify writing a Selenium or Playwright script (too one-off, too fiddly, changes too often), but that quietly eats time day after day. Whether an LLM can absorb that class of work is the real evaluation question.
Setup
The install is a straight three-step flow:
- Add the extension from the Chrome Web Store listing
- Open the side panel and sign in with a paid Claude account
- Grant per-origin permission the first time you visit a site you want Claude to operate on
The extension itself is 6.19 MiB and requests broad permissions: personally identifiable information, personal communications, web history, user activity, and website content. This scope is unavoidable given the nature of the tool (a Claude that sees and drives the DOM), but it is worth being clear-eyed about before installing.
There is no version for Chromium-based alternatives (Brave, Arc, Vivaldi), and no mobile Chrome version. That is presumably because the extension is written against Chrome-specific extension APIs.
Tasks That Actually Work
Running it as a daily driver, the work I hand off to Claude in Chrome breaks into two clean families.
The read-only family completes on the first try at a high rate:
- Summarizing an open article or PDF and producing copyable takeaway text
- Grouping and renaming spreadsheets under a Google Drive folder based on filename patterns
- Pulling attendee lists and linked documents out of an open Google Calendar event, cross-referenced against other open tabs
- Extracting records matching a filter from a list UI in an internal admin panel and dropping them into the chat
- Cross-reading five article tabs and returning shared vs. conflicting claims
The other family is post-login web page operation, and this is the class of work that Claude in Chrome opened up for me. The pattern is: I log in myself, and hand the already-authenticated tab off to Claude for the actual work.
- Filling out expense-report SaaS entries: matching receipt images against meetings in the calendar, filling in date, amount, category, and purpose
- Operating post-SSO internal panels (SaaS reached through Okta or Google Workspace) to extract or filter records
- Drafting tickets and project entries in Notion or Asana from a template plus context pulled from another tab
- Logging activity in CRM/SFA tools by cross-referencing meeting notes from another tab
- Drafting internal request forms (travel, hardware, access) from templates
This model composes cleanly with the “Claude never touches credentials” rule. A human signs in using a normal password manager, the session cookie is set, and Claude only ever operates the already-authenticated page. Passwords, MFA codes, and the credential flow itself stay outside Claude’s visibility.
Both families sit inside the same envelope: read-only or single-shot side effects, reversible, and post-login. Inside it, Claude in Chrome quietly absorbs the daily work. The class of work that Claude Code and Codex can absorb is bounded by local files, APIs, and CLIs; work that lived on the other side of a login was still mine to do by hand. Filling in that gap is the biggest before/after difference from adopting Claude in Chrome.
Tasks That Will Bite You
The other side, tasks I keep away from the side-panel Claude:
- Anything on a banking or brokerage site
- Anything involving medical or insurance records
- Anything that requires entering credentials, passwords, or API keys
- Anything that ends in an irreversible action (submit, delete, confirm payment)
This is not my personal preference; it is the boundary Anthropic themselves draw on the product page, calling out banking, health records, sensitive credentials, and workflows with one-way consequences, and asking users to review Claude’s intended prompt before letting it execute. What is being said there is not “it will not work,” but “the safety guarantees are not there yet.” The extension does include a prompt injection classifier, but a classifier is not a proof.
How the Permission Model Layers
The current Claude in Chrome splits permissions across five layers, and which layers you can touch depends on who you are.
| Layer | What it controls | Who decides |
|---|---|---|
| Permission Mode | Per-origin allowlist, or automatic-with-guardrails | User |
| Protected Actions | Categories that require explicit approval (purchases, financial transfers) | Anthropic |
| Site Blocklist | Categories Anthropic disallows outright (banking, adult, etc.) | Anthropic |
| Enterprise Policy | Org-level allowlist / blocklist and feature toggles | Org admin |
| Prompt Injection Classifier | Detects adversarial instructions embedded in page content | Anthropic |
The operationally important detail is that the middle two layers (Protected Actions and Site Blocklist) are held by Anthropic. As an individual user, you cannot loosen them (“I actually want Claude to touch my brokerage account”) and you cannot tighten them (“I never want Claude to touch a banking origin, ever, no matter what”). At this phase of the product, that is a reasonable call.
The Enterprise Policy layer is the one to check before rolling this out internally. If you distribute Claude in Chrome through Claude for Enterprise, your admins can define allowlists and blocklists at the org level. The failure mode to avoid is people installing it individually on personal plans and grinding through org-critical dashboards with no policy in the middle.
Where It Sits Among the Alternatives
Roughly how I split things now:
flowchart TD
Q1{Automating dev work or day-to-day work}
Q1 -- Dev work --> Q2{Do you need CI reproducibility}
Q2 -- Yes --> P1[Playwright / Selenium as explicit scripts]
Q2 -- No --> Q3{Are you already in a dev-tool loop}
Q3 -- Yes --> P2[Claude Code claude-in-chrome MCP]
Q3 -- No --> P3[Computer Use API one-off]
Q1 -- Day-to-day work --> Q4{Sensitive data, money, or delete involved}
Q4 -- Yes --> P4[Do it yourself]
Q4 -- No --> P5[Claude in Chrome side panel]
The claude-in-chrome MCP tools inside Claude Code are a different animal: they are how a developer in the terminal drives Chrome from inside an agent loop, not a consumer side-panel extension. In practice I use those when I want Claude Code to click through a test site as part of building something, and I use the side-panel extension for the calendar-preparation / dashboard-summary class of work.
Playwright and Selenium are as relevant as ever. If you want to run the same flow 100 times in CI, the side-panel Claude has no business being in that loop. Claude in Chrome is really for “the same shape of task, but every instance is slightly different and needs judgment,” not “the same script, run repeatedly.”
Honest Take After Running It as a Daily Driver
The most concrete thing I can say from running Claude in Chrome as a daily driver is that the class of tasks I can delegate to an AI agent stepped up a full notch. Local development work goes to Claude Code and Codex; post-login SaaS work goes to Claude in Chrome. That split is real, and it lands well on precisely the work that has no clean API and does not justify a per-flow Playwright script (expense reports, internal ticketing, form entry, cross-tool information matching).
The 2.8-star Chrome Web Store rating reads like expectation mismatch. Users install it expecting full automation across banking, purchases, and credential-flow tasks, run straight into the categories Anthropic gates off, and conclude it “does not work.” Kept inside the “read-only or single-shot, reversible, post-login daily work” envelope, my subjective failure rate is low enough that I keep reaching for it.
The second thing I would flag, from a “rolling this out to a team” standpoint, is: do not let people install it on personal plans and use it against work systems. Distribute through Enterprise with a real allowlist and blocklist. The extension has DOM read and write on any origin the user grants, and even with the classifier defenses against prompt injection, having a mental map of what it can see across your sensitive internal UIs is a prerequisite, not a nice-to-have.
Wrap-Up
- Claude in Chrome opened up in stages from an August 2025 Max-only research preview and reached Pro, Team, and Enterprise plans on December 18, 2025 (Pro rolled out over several weeks; Enterprise is off by default and admins must enable it)
- The unlocked use case is the “human logs in, Claude does the rest” model: expense reports, SaaS form entry, ticketing, CRM logging, and other post-login work that has no clean API and does not justify a per-flow script
- Sweet spot: read-only or single-shot, reversible, post-login daily work. Summarization, cross-tab research, and templated SaaS entry go through cleanly
- Weak fit (and explicitly warned against by Anthropic): banking, medical records, credential entry, one-way consequences
- Permission model is layered: Permission Mode (user), Protected Actions and Blocklist (Anthropic), Enterprise Policy (org). Roll it out with Enterprise Policy in the middle
- Positioning: Playwright / Selenium for CI-reproducible dev work, Claude Code’s MCP tooling for terminal-driven dev loops, side-panel Claude in Chrome for post-login day-to-day work inside the safe envelope
That’s all from running Claude in Chrome as a daily driver and mapping how far the “delegate to an AI agent” boundary just moved, from the Gemba.