This is the way. I use them like early day copilot in vscode. Your codebase itself is part of the prompt. So when I need the proper future proof design implemented I just do working pair programming sessions till it’s done right. As the codebase progresses I’ll see output trending in the right direction more and more, because it’s being influenced by what exists. It will eventually get to the point where I’m confident the agent can do bigger longer jobs for this area of the code with less smelly slop because it doesn’t have to be inventive anymore. Knowing what files to deliberately include and when to clean context is critical. Sometimes it’s much sooner than you think, other times it’s too soon. You wanna keep looking for that Goldilocks zone of output where your prompts (including the codebase it’s reading) is influencing the generative output just right.
@honkinwaffle I read through the docker sandbox docs. Def seems solid, but I disagree that it is complete. The major issue I see with it is while they do MITM/TLS inspection (for cred injection), they only filter on host (+ port and CIDR), no http path allow/deny. So once a host is whitelisted you get all of it.
For example whitelisting github[.]com, raw[.]githubusercontent[.]com (kind of obligatory) is a wide open prompt injection, payload delivery, and exfiltration vector. Same with package registries, and precompiled deps often live on major blob storage provider domains. They basically admit it in their docs.
Recent supply chain attacks against claude code runs malware that auths to a gh repo and commits exfiltrated data out over https from inside the sandbox (https://t.co/qgcn8fjEqt). With any coding agent having to allow a major VCS of some kind, this alone makes their egress filtering practically useless for stopping data exfil. So the only thing in docker sbx protecting creds is indirectly through cred injection. But nothing stopping them from being creative like leveraging the injected creds to drive installed clis or api calls that mint a fresh token/key it can actually read.
Non-http TCP like SSH is only by destination IP + port, not hostname. Which is almost worse, since behind LBs those IPs change. GitHub's IP ranges are a very fast moving target, so it's almost forcing you back onto the leaky https vector anyway.
The rest is mainly just DX nitpicking, not security issues. UDP (other than DNS, which they control) and ICMP are blocked at the network layer, can't be unblocked at all. Can't tell if they block websockets, but it's an http MITM proxy so a WS upgrade to an allowed host would probably just ride through.
@sammythevamp_1@honkinwaffle@sluongng I don’t need donations but thanks! But please don’t be shy if you want to contribute to the code, submit issues, fork it and use for inspiration in your own flavor of sandbox as a framework etc!
I built it before this solution was out. But It doesn’t seed containers with your hosts Claude code files, bind mount your claude project file for persistent agent memory between the host, fully featured worktree support, claude auth auth, forward socket bridges for ssh keys, gpg keys, has a http host proxy for browser events, provide provenance for agent container trust, a control plane with admin control over everything, a custom uid 1 supervisor that establishes grpc channel with a control plane, an otel opensearch monitoring stack with pre made dashboard specific to Claude code metrics and networking events, a control plane for container initialization scripts where you can setup mcps, a custom parametrized dockerfile template for Claude code, or commit-able yaml files for said template that supports file hierarchy inheritance.
Its my understanding podman does have an inherently more secure by default architecture. But personally I started developing with containers before podman was a thing. containerd is sort of king of the hill so its hard to avoid. I really don't have any good excuse otherwise, I tried podman out a few years ago in a CentOS homelab and just didn't feel a need to switch but I have no qualms or criticisms of it, I simply just don't have enough experience with it. I should check it out.
@dlwiest Because they'll sue your ass lol. Very costly and a reputational hit
"The plans listed above are intended for individual users." ... "Team plans support up to 150 seats. If your organization needs more than 150 seats, you can upgrade to the Enterprise plan" ...
I built one for myself because there was no way I was going to let an agent run on my bare metal mac and open sourced it if you wanna check it out. It’s not very user friendly at the moment with some potentially very rough edges since I don’t have an actual user base tho 😅
https://t.co/SAZanpzpMP
https://t.co/LWovbbSDLX
https://t.co/ZqkZIEcsxD
A local containerized agent sandbox ecosystem for Claude Code. Built with claude code and opus 4.5-4.7 primarily, with some help from GPT 5.4 via copilot.
Features a control plane, custom supervisor, firewall stack (envoy, coredns, ebpf), monitoring, socket forwarding, host proxy, worktree management etc.
I can launch 1+n claude code sessions in containers seamlessly without any real fear of prompt injection, destructive changes, or supply chain risks.
https://t.co/SAZanpzpMP
https://t.co/ZqkZIEcsxD
@jasonshah That’s because infosec is focused on end user, often enterprise,software. He’s talking about software packages. In product security the exact opposite is true you don’t ever just blindly update thousands of open source software libraries without knowing the impact.
@jaydrogers I have been actively building a containerized sandbox ecosystem for myself. It’s local and free to use if anyone is interested
https://t.co/dgSBEEZFL3
@IntCyberDigest SLSA is cryptographic rubber stamping. It doesn’t attest that a build isn’t infected or malicious. It just lets you verify where the build came from.
You let an AI agent run with access to a sensitive credential you were unaware of, and you weren’t leveraging rbac. Why are long lived credentials existing anywhere period? And you expect cursor to know the curl command was dangerous? How could it know it was destructive? They can’t possibly map every single API endpoint and schema in existence to guard against curl calls. And you think an API call can have a confirmation prompt guard? What? I’m sorry but this is entirely on you guys… and I probably wouldn’t be admitting this oversight publicly…
I rebuilt docker cli to orchestrate an infrastructure of claude code agents in containers within and isolated docker network. Includes an egress firewall stack and monitoring stack to see all running agent containers, their usage amounts, tool calls, outgoing traffic. Handles forwarding your settings and credentials seamlessly.
https://t.co/OvCzpzZZQo
https://t.co/SAZanpzpMP
https://t.co/ZqkZIEcsxD
@peer_rich Just run your agents in containers with egress policies and monitoring… I built one for claude code. Doesn’t matter what the prompt says if the agents container filesystem is isolated and can’t connect to arbitrary hosts / paths
https://t.co/9fkEKAloAB
https://t.co/XBHrZPIUl2
AGI = a general intelligence, unlike existing AIs that are all specialized
LLM = is inherently a specialized AI. By definition, its architecture can’t evolve into something other than a natural language processor (hence the name ChatGPT) using what is essentially a fine tuned ultra massive digital plinko board that accepts a token and directs it to the slot containing the most likely next token. It gets more accurate with more pegs but very soon they’ll be at the max limit of pegs and will have to just focus on better positioning and optimizing the number of pegs. But all it will ever do is guide tokens to slots.