Let your Coding Agent debug the browser session with Chrome DevTools MCP
138 points
by xnx
2 hours ago
| 16 comments
| developer.chrome.com
| HN
mmaunder
2 minutes ago
[-]
Google is so far behind agentic cli coding. Gemini CLI is awful. So bad in fact that it’s clear none of their team use it. Also MCP is very obviously dead, as any of us doing heavy agentic coding know. Why permanently sacrifice that chunk of your context window when you can just use CLI tools which are also faster and more flexible and many are already trained in. Playwright with headless Chromium or headed chrome is what anyone serious is using and we get all the dev and inspection tools already. And it works perfectly. This only has appeal to those starting out and confused into thinking this is the way. The answer is almost never MCP.
reply
aadishv
1 hour ago
[-]
Someone already made a great agent skill for this, which I'm using daily, and it's been very cool!

https://github.com/pasky/chrome-cdp-skill

For example, I use codex to manage a local music library, and it was able to use the skill to open a YT Music tab in my browser, search for each album, and get the URL to pass to yt-dlp.

Do note that it only works for Chrome browsers rn, so you have to edit the script to point to a different Chromium browser's binary (e.g. I use Helium) but it's simple enough

reply
Etheryte
1 hour ago
[-]
On one hand, cool demo, on the other, this is horrifying in more ways than I can begin to describe. You're literally one prompt injection away from someone having unlimited access to all of your everything.
reply
mh-
1 hour ago
[-]
Not the person you're replying to, but: I just use a separate, dedicated Chrome profile that isn't logged into anything except what I'm working on. Then I keep the persistence, but without commingling in a way that dramatically increases the risk.

edit: upon rereading, I now realize the (different) prompt injection risk you were calling out re: the handoff to yt-dlp. Separate profiles won't save you from that, though there are other approaches.

reply
sofixa
20 minutes ago
[-]
Even without the bash escape risk (which can be mitigated with the various ways of only allowing yt-dlp to be executed), YT Music is a paid service gated behind a Google account, with associated payment method. Even just stealing the auth cookie is pretty serious in terms of damage it could do.
reply
mh-
14 minutes ago
[-]
Agreed. I wouldn't cut loose an agent that's at risk of prompt injection w/ unscoped access to my primary Google account.

But if I understood the original commenter's use case, they're just searching YT Music to get the URL to a given song. This appears[0] to work fine without being logged in. So you could parameterize or wrap the call to yt-dlp and only have your cookie jar usable there.

[0]: https://music.youtube.com/search?q=sandstorm

[1]: https://music.youtube.com/watch?v=XjvkxXblpz8

reply
sofixa
8 minutes ago
[-]
Oh, that's true, even allows you to play without an account. I can swear that at some point it flat out refused any use unless you're logged in with an account that has YT Music (I remember having to go to regular YouTube to get the same song to send it to someone who didn't have it).
reply
sheepscreek
54 minutes ago
[-]
As long as it’s gated and not turned on by default, it’s all good. They could also add a warning/sanity check similar to “allow pasting” in the console.
reply
aadishv
1 hour ago
[-]
Of course I still watch it and have my finger on the escape key at all times :)
reply
glenpierce
32 minutes ago
[-]
I am in awe of the confidence you have in your reflexes.
reply
bergheim
1 hour ago
[-]
For now you are. All these things fall with time, of course. You will stop caring once you start feeling safe, we all do.

Also. AAarrgh, my new thing to be annoyed at is AI drivel written slop.

"No browser automation framework, no separate browser instance, no re-login."

Oh really, nice. No separate computer either? No separate power station, no house, no star wars? No something else we didn't ask for? Just one a toggle and you go? Whoaaaaaa.

Edit: lol even the skill itself is vibe coded:

Lightweight Chrome DevTools Protocol CLI. Connects directly via WebSocket — no Puppeteer, works with 100+ tabs, instant connection.

I feel like there's nothing fucking left on the internet anymore that is not some mean of whatever the LLM is trained to talk like now.

reply
tacitusarc
38 minutes ago
[-]
What can you do? I mentioned the use of AI on another thread, asking essentially the same question. The comment was flagged, presumably as off topic. Fair enough, I guess. But about 80% (maybe more) of posted blogs etc that I see on HN now have very obvious signs of AI. Comments do too. I hate it. If I want to see what Claude thinks I can ask it.

HN is becoming close to unusable, and this isn’t like the previous times where people say it’s like reddit or something. It is inundated with bot spam, it just happens the bot spam is sufficiently engaging and well-written that it is really hard to address.

reply
bergheim
7 minutes ago
[-]
I hear you and I agree. I don't know. Gated communities?
reply
rossvc
9 minutes ago
[-]
I've been using the DevTools MCP for months now, but it's extremely token heavy. Is there an alternative that provides the same amount of detail when it comes to reading back network requests?
reply
nerdsniper
4 minutes ago
[-]
It's probably not fully optimized and could be compacted more with just some effort, and further with clever techniques, but browser state/session data will always use up a ton of tokens because it's a ton of data. There's not really a way around that. AI's have a surprising "intuition" about problems that often help them guess at solutions based on insufficient information (and they guess correctly more often than I expect they should). But when their intuition isn't enough and you need to feed them the real logs/data...it's always gonna use a bunch of tokens.

This is one place where human intuition helps a ton today. If you can find the most relevant snippets and give the AI just the right context, it does a much better job.

reply
paulirish
3 minutes ago
[-]
The project just recently landed a CLI that's been in the works: https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/m...

* AFAIK the CLI hasn't yet been announced, but it's in the latest v0.20.0 release.

reply
mmaunder
1 minute ago
[-]
Yes. CLI. Always CLI. Never MCP. Ever. You’re welcome.
reply
senand
13 minutes ago
[-]
I suggest to use https://github.com/simonw/rodney instead
reply
meowface
9 minutes ago
[-]
Unfortunately there are like a billion competitors to this right now (including Playwright MCP, Playwright CLI, the new baked-in Playwright feature in Codex /experimental, Claude Code for Chrome...) and I can never quite decide if or when I should try to switch. I'm still just using the ordinary Playwright MCP server in both Codex and Claude Code, for the time being.
reply
tonyhschu
22 minutes ago
[-]
Very cool. I do something like this but with Playwright. It used to be a real token hog though, and got expensive fast. So much so that I built a wrapper to dump results to disk first then let the agent query instead. https://uisnap.dev/

Will check this out to see if they’ve solved the token burn problem.

reply
zxspectrumk48
1 hour ago
[-]
I found this one working amazingly well (same idea - connect to existing session): https://github.com/remorses/playwriter
reply
boomskats
50 minutes ago
[-]
Been using this one for a while, mostly with codex on opencode. It's more reliable and token efficient than other devtools protocol MCPs i've tried.

Favourite unexpected use case for me was telling gemini to use it as a SVG editing repl, where it was able to produce some fantastic looking custom icons for me after 3-4 generate/refresh/screenshot iterations.

Also works very nicely with electron apps, both reverse engineering and extending.

reply
raw_anon_1111
32 minutes ago
[-]
I don’t do any serious web development and haven’t for 25 years aside from recently vibe coding internal web admin portals for back end cloud + app dev projects. But I did recently have to implement a web crawler for a customer’s site for a RAG project using Chromium + Playwrite in a Docker container deployed to Lambda.

I ran the Docker container locally for testing. Could a web developer test using Claude + Chromium in a Docker container without using their real Chrome instance?

reply
glerk
13 minutes ago
[-]
Note that this is a mega token guzzler in case you’re paying for your own tokens!
reply
NiekvdMaas
1 hour ago
[-]
Also works nicely together with agent-browser (https://github.com/vercel-labs/agent-browser) using --auto-connect
reply
pritesh1908
19 minutes ago
[-]
I have been using Playwright for a fairly long time now. Do checkout
reply
oldeucryptoboi
24 minutes ago
[-]
I tell Claude to use playwright so I don't even need to do the setup myself.
reply
nomilk
21 minutes ago
[-]
Similarly, cursor has a built in browser and visit localhost to see the results in the browser. Although I don't use it much (I probably should).
reply
speedgoose
1 hour ago
[-]
Interesting. MCP APIs can be useful for humans too.

Chrome's dev tools already had an API [1], but perhaps the new MCP one is more user friendly, as one main requirement of MCP APIs is to be understood and used correctly by current gen AI agents.

[1]: https://chromedevtools.github.io/devtools-protocol/

reply
slrainka
28 minutes ago
[-]
chrome-cli with remote developer port has been working fine this entire time.
reply
JKolios
19 minutes ago
[-]
Now that there's widespread direct connectivity between agents and browser sessions, are CAPTCHAs even relevant anymore?
reply
Yokohiii
1 hour ago
[-]
Was already eye rolling about the headline. Then I realized it's from chrome.

Hoping from some good stories from open claw users that permanently run debug sessions.

reply