Creator of Browser Use here, this is cool, really innovative approach with ARIA roles. One idea we have been playing around with a lot is just giving the LLM raw html and a really good way to traverse it - no heuristics, just BS4. Seems to work well, but much more expensive than the current prod ready [index]<div ... notation
Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
21–30 of 43 posts
Re: Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
#22Cool to see lots of people independently come to "CLIs are all you need". I'm still not sure if it's a short-term bandaid because agents are so good at terminal use or if it's part of a longer term trend but it's definitely felt much more seamless to me then MCPs. (my one of many contribution https://github.com/caesarnine/binsmith )
I am also not sure if MCP will eventually be fixed to allow more control over context, or if the CLI approach really is the future for Agentic AI. Nevertheless, I prefer the CLI for other reasons: it is built for humans and is much easier to debug.
100% - sharing CLIs with the agent has felt like another channel to interact with them once I’ve done it enough, like a task manager the agent and I can both use using the same interface
Re: Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
#23At this point I'm fully down the path of the agent just maintaining his own tools. I have a browser skill that continues to evolve as I use it. Beats every alternative I have tried so far.
Same. Claude Opus 4.5 one-shots the basics of chrome debug protocol, and then you can go from there. Plus, now it is personal software... just keep asking it to improve the skill based on you usage. Bake in domain knowledge or business logic or whatever you want. I'm using this for e2e testing and debugging Obsidian plugins and it is starting to understand Obsidian inside and out.
Cool! Have you written more about this? (EDIT: from your profile, is that what https://relay.md is about?)
Re: Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
#24I really like this idea!
I’d like to see this other browser plugin’s API be exposed via your same CLI, so I don’t have to only control a separate browser instance. https://github.com/remorses/playwriter (I haven’t investigated enough to know how feasible it is, but as I was reading about your tool, I immediately wanted to control existing tabs from my main browser, rather than “just” a debug-driven separate browser instance.)
Re: Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
#25Re: Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
#26[dead]
Re: Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
#27Earlier quoted context omitted.
MCP let's you hide secrets from the LLM
you can do same thing with cli via env vars no?
Yes, I'm using Dagger and it has great secret support, obfuscating them even if the agent, for example, cats the contents of a key file, it will never be able to read or print the secret value itself
tl;Dr there are a lot of ways to keep secret contents away from your agent, some without actually having to keep them "physically" separate
Re: Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
#28Cool to see lots of people independently come to "CLIs are all you need". I'm still not sure if it's a short-term bandaid because agents are so good at terminal use or if it's part of a longer term trend but it's definitely felt much more seamless to me then MCPs. (my one of many contribution https://github.com/caesarnine/binsmith )
Thank you for posting binsmith, I've built something similar over the past few days and you've made some great decisions in here
Re: Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
#29Earlier quoted context omitted.
Same. Claude Opus 4.5 one-shots the basics of chrome debug protocol, and then you can go from there. Plus, now it is personal software... just keep asking it to improve the skill based on you usage. Bake in domain knowledge or business logic or whatever you want. I'm using this for e2e testing and debugging Obsidian plugins and it is starting to understand Obsidian inside and out.
Cool! Have you written more about this? (EDIT: from your profile, is that what https://relay.md is about?)
https://relay.md is a company I'm working on for shared knowledge management/ AI context for teams, and the Obsidian plugin is what i am driving with my live-debug and obsidian-e2e skills.
I can try to write it up (I am a bit behind this week though...), but I basically opened claude code and said "write a new skill that uses the chrome debug protocol to drive end to end tests in Obsidian" and then whenever it had problems I said "fix the skill to look up the element at the x,y coordinate before clicking" or whatever.
Skills are just markdown files, sometimes accompanied by scripts, so they work really naturally with Obsidian.
Re: Show HN: Webctl – Browser automation for agents based on CLI instead of MCP
#30I really like this idea! I’d like to see this other browser plugin’s API be exposed via your same CLI, so I don’t have to only control a separate browser instance. https://github.com/remorses/playwriter (I haven’t investigated enough to know how feasible it is, but as I was reading about your tool, I immediately wanted to control existing tabs from my main browser, rather than “just” a debug-driven separate browser i…
Thanks! To clarify: webctl allows you to manually interact with the browser window at any time. It even returns "manual interaction" breakpoints to stdout if it detects an SSO/login wall.
But I agree, attaching to the OS "daily driver" instance specifically would be a nice addition.