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 13 hours ago | parent | next [-]

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 13 hours ago \| parent [-]
		Thank you for the links / info! I'm looking forward to digging into this.

▲

hugs 13 hours ago | parent | prev | next [-]

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 12 hours ago | parent | prev [-]

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 12 hours ago \| parent [-]
		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).