BrowserOS

client side wasn't smooth. We initially built our agent loop inside a Chrome extension. But we kept hitting walls -- service worker being single thread JS; not having access to NodeJS libraries. So we made the hard decision 2 months ago to throw away everything and start from scratch. In the new architecture, our agent loop sits in a standalone binary that we ship alongside our Chromium. And we use gemini-cli for the agent loop with some tweaks! We wrote a neat adapter to translate between Gemini format and Vercel AI SDK format. You can look at our entire codebase here: https://git.new/browseros-agent How we give browser access to filesystem: When Claude Cowork launched, we realized something: because Atlas and Comet run their agent loop server-side, there's no good way for their agent to access your files without uploading them to the server first. But our agent was already local. Adding filesystem access meant just... opening the door (with your permissions ofc). Our agent can now read and write files just like Claude Code. What you can actually do today: a) Organize files in my desktop folder https://youtu.be/NOZ7xjto6Uc b) Open top 5 HN links, extract the details and write summary into a HTML file https://youtu.be/uXvqs_TCmMQ --- Where we are now If you haven't tried us since the last Show HN (https://news.ycombinator.com/item?id=44523409), give us another shot. The new architecture unlocked a ton of new features, and we've grown to 8.5K GitHub stars and 100K+ downloads: c) You can now build more reliable workflows using n8n-like graph https://youtu.be/H_bFfWIevSY d) You can also use BrowserOS as an MCP server in Cursor or Claude Code https://youtu.be/5nevh00lckM We are very bullish on browser being the right platform for a Claude Cowork like agent. Browser is the most commonly used app by knowledge workers (emails, docs, spreadsheets, research, etc). And even Anthropic recognizes this -- for Claude Cowork, they have janky integration with browser via a chrome extension. But owning the entire stack allows us to build differentiated features that wouldn't be possible otherwise. Ex: Browser ACLs. Agents can do dumb or destructive things, so we're adding browser-level guardrails (think IAM for agents): "role(agent): can never click buy" or "role(agent): read-only access on my bank's homepage." Curious to hear your take on this and the overall thesis. We’ll be in the comments. Thanks for reading! GitHub: https://github.com/browseros-ai/BrowserOS Download: https://browseros.com (available for Mac, Windows, Linux!)

er API, and Rewriter API have also been adopted by the W3C WebML Working Group. We've asked asked Mozilla and WebKit for their standards positions. webmachinelearning/webmcp: https://github.com/webmachinelearning/webmcp jasonjmcghee/WebMCP: https://github.com/jasonjmcghee/WebMCP Having worked on at least one web app with a name that started with "Web", I'm not surprised. /? mcp chrome: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... : - "Show HN: We packaged an MCP server inside Chromium" (today) https://news.ycombinator.com/item?id=45618536 re: browseros-mcp: https://github.com/browseros-ai/BrowserOS/blob/main/docs/bro... - "Chrome DevTools (MCP) for your AI agent" https://developer.chrome.com/blog/chrome-devtools-mcp .. https://news.ycombinator.com/item?id=45412734 (September 2025) .. : > We're launching today a public preview for the new Chrome DevTools Model Context Protocol (MCP) server, bringing the power of Chrome DevTools to AI coding assistants. > Coding agents face a fundamental problem: they are not able to see what the code they generate actually does when it runs in the browser. They're effectively programming with a blindfold on. > The Chrome DevTools MCP server changes this. AI coding assistants are able to debug web pages directly in Chrome, and benefit from DevTools debugging capabilities and performance insights. This improves their accuracy when identifying and fixing issues. How could the Chrome DevTools MCP be integrated with the Gemini Computer Use model? From https://news.ycombinator.com/item?id=45543923 : > Competency Story: The customer and product owner can write BDD tests in order to validate the app against the requirements > Prompt: Write playwright tests for #token_reference, that run a named factored-out login sequence, and then test as human user would that: when you click on Home that it navigates to / (given browser MCP and recently the Gemini 2.5 Computer Operator model) "Introducing the Gemini 2.5 Computer Use model" (October 2025) https://blog.google/technology/google-deepmind/gemini-comput... Could this help with accessibility reviews? "Lighthouse accessibility score" https://developer.chrome.com/docs/lighthouse/accessibility/s... awesome-a11y > Tools: https://github.com/brunopulis/awesome-a11y/blob/main/topics/...

-devtools-mcp which starts a fresh headless instance each time) 3. our MCP server also exposes new APIs from Chromium's C++ core to click, type, and draw bounding boxes on a webpage. Our APIs are also not CDP-based (Chrome Debug Protocol) and have robust anti-bot detection. -- Few example use cases for BrowserOS-mcp are: a) *Frontend development with Claude Code*: instead of screenshot‑pasting, claude-code gets WYSIWYG access. It can write code, take a screenshot, check console logs, and fix issues in one agentic sweep. Since it has your sessions, it can do QA stuff like "test the auth flow with my Google Sign‑In." Here's a video of claude-code using browserOS to improve the css styling with back-and-forth checking: https://youtu.be/vcSxzIIkg_0 b) *Use as an agentic browser:* You can install BrowserOS-mcp in claude-code or Claude Desktop and do things like form-filling, extraction, multi-step agentic tasks, etc. It honestly works better than Perplexity Comet! Here's a video of claude-code opening top 5 hacker news posts and summarizing: https://youtu.be/rPFx_Btajj0 -- *How we packaged MCP server inside Chromium binary*: We package the server as a Bun binary and expose MCP tools over HTTP instead of stdio (to support multiple sessions). And we have a BrowserOS controller installed as an extension at the application layer which the MCP server connects to over WebSocket to control the browser. Here's a rough architecture diagram: https://dub.sh/browseros-mcp-diag -- *How to install and use it:* We put together a short guide here: https://git.new/browseros-mcp Our vision is to reimagine the browser as an operating system for AI agents, and packaging an MCP server directly into it is a big unlock for that! I'll be hanging around all day, would love to get your feedback and answer any questions!

ing with three different ways a user could build an agent: A) Drag-and-drop workflows: Similar to tools like n8n. This approach creates very reliable agents, but we found that the interface felt complex and intimidating for new users. One tester (my wife) said: "This is more work than just doing the task myself." Building a simple workflow took 20+ minutes of configuration. B) The "one-shot" agents: This was our starting point. You give the agent a high-level goal and it does the rest. It feels magical when it works, but it's brittle, and smaller local models really struggle to create good plans on their own. C) Plan-follower agents: A middle ground where a human provides a simple, high-level plan in natural language, and the LLM executes each step. The LLM doesn't have to plan; it just has to follow instructions, like a junior employee. --- After building and trying all three, we've landed on C) as the best trade-off between reliability and ease of use. Here's the demo https://youtu.be/ulTjRMCGJzQ For example, instead of just saying "order toothpaste," the user provides a simple plan: 1. Navigate to Amazon 2. Search for Sensodyne toothpaste 3. Select 1 pack of Sensodyne toothpaste from the results 4. Add the selected toothpaste to the cart 5. Proceed to checkout 6. Verify that there is only one item in the cart. If there is more than one item, alert me 7. Finally place the order With this guidance, our success rate jumped from 30% to ~80%, even with local models. The trade-off: users spend 30 seconds writing a plan instead of just stating a goal. But they get reliability in return. Note that our agent builder gives a good starting plan, and then the user has to just edit/customize it. --- You can try out our agent builder and let us know what you think. We're big proponents of privacy, so we have first-class support for local LLMs. You can try GPT-OSS via Ollama or LMStudio and it works great! I'll be hanging around here most of the day, happy to answer any questions!