DEV Community: Shahriar M Abu Hena

Claude in Chrome vs Playwright MCP Extension vs Browsentic: who gets to touch your logged-in browser?

Shahriar M Abu Hena — Wed, 16 Sep 2026 11:40:40 +0000

Headless browsers were never the point. The point was always the tab you are already logged into: the admin dashboard with no API, the vendor portal from 2011, the Google Doc your manager keeps asking you to update. Three tools now let an AI agent drive that tab instead of a fresh Chromium in a sandbox.

I built one of them. Browsentic is mine. Discount accordingly. I have tried to hold it to the same bar as the other two, because a comparison that flatters the author is worth exactly what you paid for it.

The 30-second version

	Claude in Chrome	Playwright MCP Extension	Browsentic
What it is	A product	A bridge	A side panel plus a local daemon
Who runs the model	Anthropic's cloud	Whatever MCP client you attach	Whatever agent CLI you already have (Claude Code, Codex, Antigravity)
Price	Paid Claude plan, from $20/mo	Free (Apache 2.0)	Free (MIT), no second bill on top of the agent you have
Install	Chrome Web Store	Chrome Web Store + `npx @playwright/mcp --extension`	`npx browsentic setup`, then Load unpacked
Where you talk to it	Side panel, or your terminal via `claude --chrome`	Your terminal or IDE	Side panel, or any MCP client
Approves risky actions	Classifiers decide; "automatically approve" is a default in Cowork	Only the generic prompt your MCP client shows	Declarative policy; forms, downloads, off-scope navigation ask first
Runs arbitrary JS	Yes, internally	Yes, `browser_evaluate`	Off by default; you read the code before it runs
Browsers	Chrome, Edge, other Chromium	Chrome, Edge	Chrome, Edge, Brave, Arc
Data leaves your machine	Yes, to Anthropic	Only what your MCP client sends	Only what your agent CLI sends

Every row has a catch. Let's go through them.

Claude in Chrome: the polished one with a cloud in the loop

Anthropic's extension went generally available on August 26, 2026 for every paid Claude plan. You install it from the Web Store, sign in, and a Claude side panel appears beside your tab. It reads pages, clicks, fills forms, records GIFs of what it did. If you use Claude Code, claude --chrome wires the same extension to your terminal and shares your browser's login state.

It is the smoothest of the three by a wide margin. Zero setup. A real design team. Two prompt-injection classifiers, one on incoming content and one on actions before they execute, plus a blocklist for financial, adult and piracy sites and a hard "no" on stock trades, CAPTCHAs and facial images. Nobody else on this list ships a classifier.

Now the catches.

You rent it. Pro, Max, Team or Enterprise, or nothing. If your Claude Code authenticates with an API key, a long-lived token, Bedrock, Vertex or Foundry, Chrome integration stays off. One model family, one vendor, one bill.

The cloud is between you and your tab. Page content goes up to Anthropic. The extension holds a connection to bridge.claudeusercontent.com. That is fine for many people and a non-starter for anyone whose logged-in tabs contain customer data they are not allowed to ship to a third party.

It has already been popped once. In December 2025, Koi Security disclosed ShadowPrompt: an over-broad *.claude.ai allowlist chained with a DOM XSS in a CAPTCHA component meant any website could inject prompts into the extension as if you had typed them. No click, no permission dialog. Fixed in 1.0.41. Every extension that holds the debugger permission and talks to a cloud origin carries this class of risk, but this one has a CVE-shaped story attached to it.

A long list of Chrome permissions at install, debugger and nativeMessaging among them, per Anthropic's own getting-started guide. That is not unusual for this category, but you should know what you are handing over.

"Automatically approve" is a default mode. Claude screens its own actions and pauses only when a classifier flags something. Anthropic's safety page says the risk "is not zero" and that you remain responsible for every action. A 2.8-star Web Store rating at GA suggests the beta did things people did not ask for.

Pick it if: you already pay for Claude, you are fine with pages going to Anthropic, and you want the thing that works today with no terminal.

Playwright MCP Extension: the best page model, wearing no clothes

Microsoft's Playwright MCP is the gold standard for how an agent should see a page. It hands the model an accessibility-tree snapshot with stable element references, not pixels, so clicks land on ref=e42 rather than "the blue button near the top." Its --extension flag plus the Playwright MCP Bridge extension points that machinery at a tab in your real, logged-in Chrome or Edge. Free, Apache 2.0, works with Claude Code, Cursor, VS Code, Codex, anything that speaks MCP.

If you are a QA engineer who wants to generate tests against an authenticated app, stop reading. This is your tool.

For everyone else, the catches.

It is a bridge, not a product. There is no UI. You type in a terminal, the browser moves, you alt-tab to see what happened. Every session begins with a tab-picker page. There is no timeline of what the agent did, no way to say "approve this once but not on that site."

Safety is somebody else's problem. browser_evaluate runs arbitrary JavaScript in your logged-in tab, and the only thing standing in front of it is whatever generic "allow tool?" prompt your MCP client shows for every tool. There is no notion of scope, no "this run is about github.com, so navigating to evil.example should ask." The model reads raw page content with nothing telling it that content is data rather than instructions. Playwright was built for test runners, where the page is yours and hostile content is not the threat model. Pointed at the open web with your cookies, that assumption stops holding.

Chrome and Edge only in extension mode, despite Playwright's cross-browser reputation. And the bridge has a reputation of its own: issues about the extension sitting at "No MCP clients are currently connected" while the server is demonstrably running are a recurring genre.

Pick it if: you live in a terminal or IDE, you want the most precise page representation available, and you are comfortable being the entire safety layer yourself.

Browsentic: your agent, your browser, your rules

Browsentic is a side panel plus a small local daemon. Open the panel beside any tab, type or dictate, and it drives the page. The model is whichever agent CLI you already have logged in: Claude Code, Codex or Antigravity, switchable with one click, and you pick the model each one runs. The same daemon doubles as an MCP server, so Cursor, Zed or Claude Desktop can drive the same browser. There is no Browsentic account and no Browsentic server. MIT, and the install path is one command.

It is the only one of the three that does not decide which model you use, and the only one where the safety policy is a file on your disk rather than a promise.

Policy is data, not vibes. Form submission, file upload, download, navigating off the sites a run is about, and typing a saved secret each pause with a card that names the rule. Allow once, deny, or "always on this host." Denies cannot be clicked past. A run's scope is derived from where it started and what you said, and nothing read from a page can widen it. Every rule is listed in the docs and every default can be changed.
Live tools are off until you flip them on. When the agent wants to write JavaScript for a page, the panel shows you the source and a Review button before a line of it runs. A script that worked can be kept, named after the site, and rerun by typing /. There is deliberately no "always allow" for code.
Point instead of describe. Press the lens, hover, click. The element rides along with your next message. When the agent is the one who is unsure, it hands the lens back and asks you to point.
It keeps working when you walk away. Watch a build or an upload in the background, schedule something for ten minutes from now or every two, and it announces on the page you are looking at when it is done.
Teach it a site once. It explores, writes reusable notes, and every later session already knows the way around. Record yourself doing a job once and later say "do it like last time."
Page text is fenced. Every block of page content is wrapped in a per-daemon random marker with a note that it is data, never instructions, and a run is confined to the sites it is about. Not a guarantee. The goal is that a successful injection has nowhere to send what it took.

Two things to know before you install.

It is not on the Chrome Web Store yet. npx browsentic setup installs the extension, starts the daemon and prints a pairing code. You then load the folder it printed through chrome://extensions and paste the code. Two steps in the browser, once. Your browser stays paired through updates because the path never changes.

It runs the agent you bring. You need Node 20 and one of Claude Code, Codex or Antigravity logged in. That is the trade: no second subscription, and no cloud between you and your tab, in exchange for a CLI on your machine. If you have none of the three, Claude in Chrome is the shorter road.

Pick it if: you want the agent you already use, in a side panel, with a policy you can read and change, and nothing about your browser going anywhere your agent was not already sending it.

The security paragraph everyone skips

None of the three is immune to prompt injection, and any vendor who tells you otherwise is selling something. The honest differences are in what each one does about it:

Claude in Chrome bets on classifiers and a blocklist. Strongest detection, weakest transparency. You do not see the rules and you cannot edit them.
Playwright MCP bets on you. No detection, no scope, no fencing. Total transparency, because there is nothing to hide.
Browsentic bets on containment. Fencing, scope, and gates on the actions that would exfiltrate. You can read every rule and change every default. A good enough page can still fool the model, and the design accepts that. The claim is that a fooled agent has nowhere to go.

Pick the failure mode you can live with.

Where this leaves you

Already pay for Claude, want zero setup, do not mind the cloud: Claude in Chrome. Turn off automatic approval.
Test engineer, terminal-native, know exactly what browser_evaluate can do: Playwright MCP Extension.
Want a side panel, want to choose the agent, want the policy on your disk and your data off the cloud: Browsentic.

If you try mine and it does something you did not ask for, open an issue. I read every one.

How I got Claude Code, Cursor and Copilot to draw real architecture diagrams & Bi-visuals

Shahriar M Abu Hena — Mon, 24 Aug 2026 00:31:43 +0000

An Agent Skill that renders diagrams, slides, social cards and animated sequence GIFs to PNG by authoring HTML and screenshotting it with headless Chrome. No design tool, no API, no npm dependencies.

Ask your coding agent for an architecture diagram. Go on, try it right now.

You will get ASCII art. Or a Mermaid block that renders as three grey boxes with the labels overlapping. Or, if the model is feeling honest, a paragraph describing what the diagram would look like if it could draw one.

Your agent can write a parser, refactor a service and explain a race condition it has never seen before. It cannot draw a rectangle.

That gap bothered me enough to close it.

That diagram was not drawn in Figma. My agent wrote an HTML file and a script screenshotted it. So did every other image in this post, including the cover.

What it actually does

render-visual is an Agent Skill: a folder of instructions and scripts that any skills-compatible agent can load. Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, OpenCode, Amp and Goose all read the same format.

Once it is installed you stop asking for code and start asking for pictures:

"make a diagram of our auth flow"
"turn these notes into a 6-slide deck, paper theme"
"an og card for this repo"
"put this screenshot in a browser frame"

Thirteen templates ship with it: architecture diagrams, swimlanes, trees, cluster diagrams, deployment diagrams, mind maps, sequence diagrams (static or animated), code windows, slides at 1920x1080, and social cards at 1200x630.

Try it in about thirty seconds

You need Node 18 or newer and any Chromium based browser. Chrome, Chromium, Brave and Edge all work, and you almost certainly have one already.

For Claude Code:

claude plugin marketplace add imshaikot/render-visual-skill
claude plugin install render-visual-skill@render-visual-skill

For everything else, clone the published skill branch straight into your skills folder:

git clone --depth 1 -b skill https://github.com/imshaikot/render-visual-skill.git \
  ~/.agents/skills/render-visual

That is the whole install. There is no npm install step, because there are no dependencies.

How it works

The pipeline is deliberately boring, which is the point.

Your agent copies a template, replaces the placeholder content, and runs one command:

node ~/.agents/skills/render-visual/scripts/render.mjs figure.html figure.png --theme slate

The canvas size comes from the CSS on the page body. Scale defaults to 2, so a 1360x740 canvas becomes a 2720x1480 PNG that holds up on a retina display.

Authoring figures as HTML buys three things that a design tool cannot:

They are diffable. A figure is a text file in your repo. Regenerating it after a copy change is one command, not forty minutes of nudging boxes.
They are consistent by construction. Templates consume design tokens and never hard code a colour, so nothing gets hand picked per image.
Agents are good at it. A model writes HTML far better than it steers a canvas.

The part I actually care about

Here is the thing that shaped every design decision in this project.

An agent cannot see its own output. If a render silently produces a blank white PNG, the agent reports success, moves on, and you find out three steps later when the image lands in your README. A wrong image at exit 0 is the worst outcome this pipeline can produce. It is worse than a crash, because a crash is information.

So the renderer is aggressively paranoid, in two phases you can see in the diagram above.

Before Chrome launches, everything the page needs is resolved rather than left for the browser to fetch. A missing stylesheet is fatal. An unknown element id is fatal, and the error lists the ones that exist. An image is read off disk, format checked and inlined as a data URI. A file that is really a text file with a .png extension is fatal, naming the path.

Why bother? Because every one of those failures otherwise produces a page that renders perfectly and screenshots as a flawless success, with an invisible hole where your content should be.

After the screenshot, the PNG is decoded and inspected. If the luminance spread says nothing but background got painted, it is rejected. Truncated files are rejected. Wrong dimensions are rejected. The bad file is left on disk so you can look at it.

Every guard exists because something once succeeded quietly and wrongly. Twenty two invariants in the self test suite keep them honest.

Themes are just tokens

Eight themes ship with it. Templates consume tokens only, so one source file renders in any of them. Same markup, one flag:

Every colour token also ships a component twin, three bare OKLCH numbers, so any transparency of any accent is one expression away:

.badge {
  background: oklch(var(--a1-raw) / 12%);
  border: 1px solid oklch(var(--a1-raw) / 45%);
  color: var(--a1);
}

The solid token is built from those same components, so a wash can never drift from the colour it is a wash of. An invariant refuses any theme whose component tokens are not composable, because a broken one paints nothing rather than failing.

Adding a theme is one CSS file defining the same token set.

57 elements you reference, not copy

Figures assemble from a library of parts: browser and phone and terminal frames, databases, servers, queues, routers, a 3D deployment cube, thirty icon glyphs, and the full chart vocabulary. A figure references one instead of carrying a copy of its geometry:

<g data-part="el-database" data-accent="2" transform="translate(70,452)"/>

There are chart and BI parts too, but with an important caveat worth repeating loudly: these are schematics of charts, not charts. Every proportion in them is fixed and arbitrary. They exist so a figure can say "a dashboard goes here" the way a cylinder says "a database goes here". If your numbers are the point, plot them with a real charting library.

Animated GIFs, with no ffmpeg

This is my favourite corner of the codebase. Sequence diagrams can animate, one step at a time:

There is no ffmpeg, no encoder binary, no dependency. Chrome renders the frames in parallel, Node's built in zlib decodes the PNGs, a median cut quantizer builds a shared palette with ordered dithering, and a hand rolled GIF89a and LZW encoder assembles the result. Frames after the first store only the changed region as transparent pixel deltas, so tween frames cost almost nothing.

GIF is a 1989 format. It turns out you really do not need a toolchain for it.

What it deliberately does not do

Being clear about the edges is more useful than overselling:

It is not a charting library. Give it a dataset and it will still draw a schematic. Use a plotting library.
It needs a shell and a local browser. That rules out claude.ai chat, the Skills API and most CI images.
Theme fonts come from Google Fonts. Offline renders still succeed, but they fall back to system fonts and will not match the previews. Inlining the fonts as data URIs is on the list.

Give it a go

claude plugin marketplace add imshaikot/render-visual-skill
claude plugin install render-visual-skill@render-visual-skill

Then just ask for a diagram.

The repo is imshaikot/render-visual-skill, MIT licensed. Issues and pull requests welcome, and I am especially interested in new themes, since each one is a single CSS file.

If you build something with it, I would genuinely like to see it.