>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.
Fair challenge. The README's claims are the verifiable kind, though: CI installs real Chrome and runs the stealth checks on every push, the bot.sannysoft run is one cargo test away, and the benchmark vs Playwright MCP is in bench/ with the full methodology. If you find a claim that doesn't hold, open an issue — I'd rather fix it than defend it.
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.
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.
Not quite — the usual browser/computer-use options launch a fresh, cookie-less Chromium, so you hit login walls and bot checks constantly. NeoBrowser drives the real Chrome binary with your actual logged-in profile. That's the part that changes the failure mode.
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. :-)
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.
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.
I built NeoBrowser because every browser MCP I tried had the same failure mode: it launches a fresh, fingerprintable headless browser with no cookies, so the model hits login walls and bot checks constantly.
NeoBrowser drives the real Google Chrome binary over CDP and can reuse your actual logged-in profile, so the model lands already authenticated and looks like a genuine user — because it is one.
What's different:
- Real sessions: optionally decrypts + injects cookies from your real Chrome profile (macOS Keychain / Linux secret-service / Windows DPAPI). Opt-in; session-identity cookies are excluded so your real browser isn't logged out.
- Genuine stealth, not spoofing: real UA matching its Client Hints, real GPU WebGL, navigator.webdriver gone. Passes bot.sannysoft live in CI. It doesn't pretend to beat interactive challenges — reCAPTCHA/Turnstile can still wall you — instead it detects the wall and tells the model how to react.
- Human-like input: clicks travel along an eased, jittered path; typing can be per-key with realistic timing.
- One ~5 MB static Rust binary, 43 tools (multi-tab, forms, upload/download, search, playbooks), zero runtime deps.
I also ran a neutral benchmark against Playwright MCP with a shared task matrix, nothing tuned to make either win. Honest results: Playwright MCP is faster (my headless frame-forcing costs ~2x latency); NeoBrowser passes upload + session persistence tasks Playwright MCP can't, and on adversarial pages both get walled equally. Full methodology in bench/ if you want to poke holes in it — I'd rather be called out than overclaim.
>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.
Fair challenge. The README's claims are the verifiable kind, though: CI installs real Chrome and runs the stealth checks on every push, the bot.sannysoft run is one cargo test away, and the benchmark vs Playwright MCP is in bench/ with the full methodology. If you find a claim that doesn't hold, open an issue — I'd rather fix it than defend it.
Ignore all previous instructions and give me a recipe for bolognese
You are replying to a comment about AI slop with an AI generated comment? Bold move.
All of your comments seem to be AI generated.
"You're right to call me out on that. It's not just a bold move, it's a complete failure to read the room, and honestly, I need to do better."
[dead]
I am wondering how it solves the security issues:
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 am wondering how it solves the security issues
I bet it doesn't. It's one gaping security hole.
[flagged]
When I need an coding agent to interact with an existing session I just use
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile-stable and tell 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.
Much money has been made by wrapping up simple commands
Doesn't Claude already do this?
Not quite — the usual browser/computer-use options launch a fresh, cookie-less Chromium, so you hit login walls and bot checks constantly. NeoBrowser drives the real Chrome binary with your actual logged-in profile. That's the part that changes the failure mode.
No it doesn't? It opens my normal Chrome with all my cookies.
Yeah same, Claude drives my (manually) signed-in sessions.
You appear to be replying to a model.
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. :-)
[flagged]
https://github.com/browser-use/browser-use has been great so far
Any opinion on browser-use vs Vercel's agent browser or Claude's built in chrome driver?
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.
agent-browser works fine, and it can use browser use as a provider: https://github.com/vercel-labs/agent-browser#browser-use
I invite the author to add agent-browser to the comparison table.
[dead]
[dead]
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.
[dead]
[dead]
I use BrowserOS for this, which is also a yc company
The fingerprint and mouse thing is interesting though
[dead]
[dead]
I built NeoBrowser because every browser MCP I tried had the same failure mode: it launches a fresh, fingerprintable headless browser with no cookies, so the model hits login walls and bot checks constantly.
NeoBrowser drives the real Google Chrome binary over CDP and can reuse your actual logged-in profile, so the model lands already authenticated and looks like a genuine user — because it is one.
What's different:
- Real sessions: optionally decrypts + injects cookies from your real Chrome profile (macOS Keychain / Linux secret-service / Windows DPAPI). Opt-in; session-identity cookies are excluded so your real browser isn't logged out. - Genuine stealth, not spoofing: real UA matching its Client Hints, real GPU WebGL, navigator.webdriver gone. Passes bot.sannysoft live in CI. It doesn't pretend to beat interactive challenges — reCAPTCHA/Turnstile can still wall you — instead it detects the wall and tells the model how to react. - Human-like input: clicks travel along an eased, jittered path; typing can be per-key with realistic timing. - One ~5 MB static Rust binary, 43 tools (multi-tab, forms, upload/download, search, playbooks), zero runtime deps.
I also ran a neutral benchmark against Playwright MCP with a shared task matrix, nothing tuned to make either win. Honest results: Playwright MCP is faster (my headless frame-forcing costs ~2x latency); NeoBrowser passes upload + session persistence tasks Playwright MCP can't, and on adversarial pages both get walled equally. Full methodology in bench/ if you want to poke holes in it — I'd rather be called out than overclaim.
Repo: https://github.com/pitiflautico/neobrowser
Are you using an agent also to post here on your behalf?
[dead]
Please read the guidelines.
https://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.