I put Claude Code in an Incus VM, let it go in YOLO mode, locked down the firewall, and started losing my mind managing IPs. Every time Claude needed to hit a new service (a package registry, an API, a webhook), I'd have to SSH in and update the firewall. Plus, I didn't have the ability to allow GETs while blocking POST/DELETE, which I really wanted. And the jobs I needed to run outside the VM? That was a whole other mess of selective approvals. I kept asking: why is giving a coding agent internet access so painful? The answer turned out to be: you don't need a firewall per endpoint. You need a proxy with a brain. Trollbridge is a local HTTP/HTTPS proxy that sits between your coding agent and the internet. The agent still gets YOLO locally (read files, write code, run builds) but outbound traffic goes through a gate: - Known destinations auto-approve via allow rules - Differentiate by: hostname, verb (GET vs POST etc), path - Unfamiliar requests pause in a terminal UI for you to review - Your decisions become sticky policy, you never review the same endpoint twice - Optional LLM advisor (point it at your local litellm/vllm/etc, nothing leaves your network) - Full JSONL audit log with per-request correlation IDs One curl command: curl -fsSL https://trollbridge.dev/install.sh | sh trollbridge quickstart Set HTTPS_PROXY and forget it. The troll guards the bridge — your agent stays free locally, but nothing weird crosses. GitHub: https://github.com/dandriscoll/trollbridge Quick notes before you ask: - Not a sandbox. I pair it with Incus for local isolation. Trollbridge just gates the network, which is the part that was actually painful. - Not mitmproxy. The rule engine, sticky policy, LLM advisor, and approval TUI are what differentiate it. Plus no Python deployment story. - LLM is optional and local. Advisor is off by default. When you turn it on, point it at your own model. Applicable if you're running Claude Code, Github Copilot, Codex, Gemini CLI, or similar agents in containers, VMs, WSL, etc. |