Live data from Hacker News

Chrome DevTools MCP (2025)

developer.chrome.com

31–40 of 266 posts

Re: Chrome DevTools MCP (2025)

#31
post #28
post #7

Earlier quoted context omitted.

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…

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.

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

Re: Chrome DevTools MCP (2025)

#34
post #33

I suggest to use https://github.com/simonw/rodney instead

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.

Re: Chrome DevTools MCP (2025)

#35
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?

Re: Chrome DevTools MCP (2025)

#36
post #31
post #28

Earlier quoted context omitted.

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.

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.c…

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).

Re: Chrome DevTools MCP (2025)

#37

Earlier quoted context omitted.

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 tog…

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 time…

I hear you and I agree. I don't know. Gated communities?

Re: Chrome DevTools MCP (2025)

#38
post #35

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?

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.

Re: Chrome DevTools MCP (2025)

#40
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.
Post reply on HN