felarof

I do this via BrowserOS -- https://github.com/browseros-ai/BrowserOS

It has an in-built MCP server and I use it with claude code, codex and like it quite a lot.

> “Every month, alert me to any fluctuations in product cost and which items in my Square catalog are affected. Highlight any items where my COGS exceeds 35%. All the invoices are available in my email.” That would be incredibly powerful.

You could try this use case on on agent builder even today. We also have a scheduled tasks for you to schedule it to run monthly

> Have you ever thought about a marketplace for premade workflows?

We want to do this and are moving towards that! But we first need to make the premade (or user published) workflows very reliable.

There are bunch of tedious / routine tasks that AI can automate.

I think the big hurdle is mostly education / shift in mindset. We are so used to doing the task manually that most of us (including me) don't pause to think if I should be doing this or can I give to an agent.

You can't run shell commands though. Bash is the most powerful tool in claude code!

BrowserOS should work with agent browser as well in headless mode!

On top of that, if you want headful mode, you can use our MCP server https://docs.browseros.com/features/use-with-claude-code

Would love to understand your use case! You can hit me up at nithin[at]browseros.com

> You guys need some marketing help. There’s a lot of potential here, but you don’t do a good job of selling it.

Thank you for the feedback. Ack, we need to do a better job of marketing.

> How do you plan to monetize it? Our goal is to eventually to sell license for enterprise browsers.

At the moment, our product is designed for headful mode.

But if you want to use our browser in headless and use playwright that would work too! (we are chromium fork)

gpt-oss 20B works well. You'll want at least 12k context length for agent mode.

Thanks!

> whole Browser and not a Chrome Extension argument

Both of us are definitely biased to think our own approach is better :)

But without owning the binary, we couldn't shipped today's feature -- Agent with access to your filesystem and being able to run shell commands like Claude Cowork.

> your interface is still literally a chrome extension side panel

Yep, our interface is a chrome extension to make iterating on the UX faster. But it uses a ton of C++ APIs that we expose under `chrome.browseros.*`

> Your workflow pipeline is really cool! Any blog post/summary on how you set it up?

Thanks! We'll look into publishing a blog soon!

We are still in early versions of the feature! Haven't released on our repo yet.

What use case did you have? Happy to show a demo of current version we have (you can hit me up on discord or slack -- links available on our repo)

Thanks!

> how is it reliably enforced?

At the chromium level, you have access to every single DOM element and coordinate space around it. So, when a click happens either user or agent, we have a neat way of enforcing required action (either allow it or nullify the click).

We are still at early version. And mostly targeting enterprise sites (like SAP) which don't change that often.

What use case did you have in mind?

Ohh, interesting, technically this should already be possible. Because we already package gemini-cli into the sidecar (bun) binary. We just have to create a good UX.

What angle are you looking at this from? Is it for convenience? Or do you not like terminal UI and need a web-friendly UI for these agents?

Thanks for initial feature request! We do read every single request :)

Yes, we expose BrowserOS as an MCP server -- that you can use from claude code, cursor, opencode, etc -- https://docs.browseros.com/features/use-with-claude-code

MCP server works out of box (unlike Chrome DevTools MCP which requires tricky setup).

> if you're interacting with like salesforce or a customer support tracker or an issue tracker or something you're likely using a webapp

Precisely. I think most knowledge work (especially at business) still happens browser. That is the workflow we want to target!

Good question. We think the browser is becoming the new OS. It doesn’t really matter anymore if you’re on Windows, macOS, or Linux—the browser is where most work already happens.

We see a future where it’s the main gateway to everything, and where agents live and work alongside you inside the browser. That’s why we call it BrowserOS. :)

You have a great business sense!

There is an open source alternative -- browserOS.com

This is exactly our vision as well!

But we want to enable you to run these automations using local models, which would be secure and privacy-first

https://git.new/BrowserOS

You should try us :) open-source and privacy-first alternative to Atlas -- https://github.com/browseros-ai/BrowserOS

Thank you!

> curious about your anti-bot detection implementation at the C++ level. Are you modifying specific Chromium fingerprinting.

TLDR basically most browser automation platforms use CDP or CDP based APIs and websites are able to detect it as bots. We built new C++ APIs into rendering engine for type, click, extract which are not CDP based and surprisingly don't get detected by most websites.

> auth states I'm not fully sure I understand the issue here. Are you referring to same web app but tasks require different user-logins?

I see. Let me know if I got it correctly: if the UI of our browser looked different than Chrome, you would use that?

We kept the UI same because we felt people tend to have affinity towards using something they are familiar with.

Ohh man, this definitely hurts. We were a team of 2 until recently and we've been working hard to get through the backlog of feature requests as fast as possible.

I think we've definitely improved the product a lot since we launched, you should try it out!

The BrowserOS-as-MCP server we believe is a nice useful + differentiated feature that other browsers don't have. You can use BrowserOS with claude-code, claude-desktop or gemini-cli for many useful things!

Hmm I've tried. Google chrome doesn't allow starting `--remote-debugging-port` on main profiles. Logs below from my MacOS. not sure if it allows on other OSes.

``` [I] ~ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-logging=stderr --remote-debugging-port=9445 (base) [27920:145785320:1017/131556.797325:INFO:components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc:206] No machine level policy manager exists.

DevTools remote debugging requires a non-default data directory. Specify this using --user-data-dir. ```

haha fair point. but here you can clone any website's design as inspiration to build on top of it

good question. key difference is MCP server is built right into the browser and works with your logged sessions. One-click to connect, no CDP setup needed. Also supports multiple parallel connections via MCP http transport.

Haha, we should integrate this into the browser we are building! https://github.com/browseros-ai/BrowserOS

Wow, this is cool!

You should open source this and let other people contribute and build apps that work inside this sim. I would love to build a version of our browser into this. (https://github.com/browseros-ai/BrowserOS)

Browser that helps FOCUS is a great insight!

We are working on best bookmark manager already.

Ohh, interesting!

Curious what is your use-case?

> Multiple profiles with different sets of cookies in the same window.

This would be cool, will look into this.

> Using a consistent design language. Don't use 4 sets of UI fonts and 7 color schemes in the same browser window.

Agree, we want to improve UI/UX much more. If you are designer/frontend engineer (or anyone reading is), please hit me up -- nithin[at]browserOS.com

This is a bold vision!

Framework-like laptop but for browser :)