[moss_dog]

I'd love to be able to lock down the browser to only allow certain URLs (e.g. localhost) so I can give Claude (and other tools) carte blanche to use browser automation (rather than manually approving each command). Is this something on your radar / roadmap?

[ramoz]

If using Claude Code, a simple hook can govern `browser_navigate` (mcp)

A custom sh script or something for whitelists would take ~5min to setup.

For more robust governance (many policies), you can write Rego using https://github.com/eqtylab/cupcake

https://code.claude.com/docs/en/hooks#mcp-tool-naming

[moss_dog]

Thank you for the links / info! I'm looking forward to digging into this.

[hugs]

fully aware of the "blast radius" risk of using claude to do stuff. i'm doing all my vibium dev in a vm using UTM (and you should, too!). wonder if there are some network rules we can add.

i did post a v2 roadmap on the github repo. might be time to start the draft for v3!

[falcor84]

As I see it, the only real solution is to put it into a container that has a firewall with a short whitelist.

[moss_dog]

I was looking into this earlier -- presumably you'd also need to allowlist Claude itself (whatever endpoints it hits to run inference etc). VM firewall gets a little trickier with Claude's web search tool, too.

The solution I landed on recently was to locally modify the Chrome devtools MCP to launch the browser instance with strict network restrictions. I believe the implementation used `--host-resolver-rules`, blocking all URLs by default with an environment variable to control the allowlist (which, in hindsight, Claude can easily work around if it needs to -- I should probably just hard-code the allowlist).

[michelb]

Maybe this is something: https://github.com/vibheksoni/stealth-browser-mcp