Interesting, I will have to check this out as a lot of what I do everyday involves asking claude and chat go use my signed in profile, I even built a skill for it with some other tools.
browser-use is a lot more capable and generally more efficient, and a lot easier to embed in other programs than Claude's driver. I haven't used Vercel's agent browser enough to speak to it.
That's supported as a first-class mode: NEOBROWSER_ATTACH_PORT=9222 attaches to your running Chrome and never patches or kills it. The cookie-import path exists for when you'd rather not keep a debug port open.
This pattern of using original source code and rewrite to improve them (and get rid of technical debt) is very real. I did one for an old app in Objective C, move it to Flutter and said goodbye to my old //TODOs. And get an Android build as a bonus. :-)
>It doesn't pretend to be invisible: when a site throws an interactive challenge (reCAPTCHA, Turnstile) NeoBrowser detects it and hands control back with a real-session or human path — that honesty is what makes it dependable.
Maybe it's just me, but if you can't be bothered to clean up your vibecoded README, I'm going to assume I'd be better off just vibecoding my own version of this solution.
I saw opt-in, file permissions and SSRF in README, but I do not see:
domain allowlist;
human approval before submiting/deleting;
persistent audit record after operations;
how to revoke a previously granted access;
The prompt injection may also induce the agent to perform write operations.
Reuse the real user-login session also delegate the user's full authority to the agent, which obviously has potential security issues.
The point is, the more real authority the agent has, the more important the responsibility the agent must take, which I think should be designed in from the beginning.
Domain allowlist is in: NEOBROWSER_DOMAIN_ALLOWLIST=github.com,.docs.rs — navigate rejects anything not listed with an error that names the allowed hosts. Exact hosts or .suffix, opt-in (unset = no restriction). Appreciate the push on this one.
I've been using the Chrome CDP skill for Claude Code with great success for test automation purposes (locator detection, troubleshooting mobile layout, and so on). I found it here on HN: https://github.com/pasky/chrome-cdp-skill
I remember seeing another Chromium-based "MCP-focused" browser at that point in time, but I can't remember what it was called.
35 comments
[ 0.26 ms ] story [ 30.4 ms ] threadhttps://news.ycombinator.com/newsguidelines.html
> Don't post generated text or AI-edited text. HN is for conversation between humans.
All of your comments are AI Slop.
I invite the author to add agent-browser to the comparison table.
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile-stable and tell it
The fingerprint and mouse thing is interesting though
Maybe it's just me, but if you can't be bothered to clean up your vibecoded README, I'm going to assume I'd be better off just vibecoding my own version of this solution.
All of your comments seem to be AI generated.
I saw opt-in, file permissions and SSRF in README, but I do not see:
domain allowlist; human approval before submiting/deleting; persistent audit record after operations; how to revoke a previously granted access;
The prompt injection may also induce the agent to perform write operations.
Reuse the real user-login session also delegate the user's full authority to the agent, which obviously has potential security issues.
The point is, the more real authority the agent has, the more important the responsibility the agent must take, which I think should be designed in from the beginning.
I remember seeing another Chromium-based "MCP-focused" browser at that point in time, but I can't remember what it was called.