Skip to content

Comment on OpenChamber: An Agentic Development Environmentparent

Comments

this looks prettttttty slick i might dive in later.

are people using these things but isolating agents to some sort of containerization individually or do you have like one big dev env ? probably time i get around to sorting a better dev container strategy just to isolate agents here but trying to think of the best way to set this up locally.

I had another comment in a thread last week about this: https://news.ycombinator.com/item?id=49111625

I really think that using something like Paseo (I use Ouijit[1] because I think it's actually a step ahead of where most of these multiplexers are) and nono[2] is basically the best coverage you can have, and really lets you go crazy with auto mode or permission skipping withiout having to worry about any security concerns.

A lot of people lean into the VMs but realistically it's not actually doing a lot of the security work that you need and leaves you wide open to prompt injection/exfiltration attaacks. The flexibility of a good nono setup (which is easy because they ship a nono skill that claude can consume) actually locks things down significantly better

1. https://ouijit.com/ 2. https://nono.sh/

It’s just a personal preference, to be honest, so I wouldn’t overengineer it yet. In my case, I run it in a VM behind Tailscale. The main reason is that I want it to be able to install or use whatever tools it needs without contaminating my main machine. It can expose anything I need over Tailscale. So for me, it’s basically just a cheap, throwaway machine.

I have a VM in which I run my general compute. In that VM I use incus linux container and run these tools as unauthorized user of the container. That should be reasonable security while having nice control for resources.

The split I've settled on: git worktrees for parallelism, containers only when I actually need isolation from the host.

Worktrees are cheap because they share the object store, so N agents each get their own working dir + branch without N full clones, and teardown is just `git worktree remove`. That solves the common case — two agents stomping each other's uncommitted files on the same repo. What it does NOT give you is isolation of the filesystem outside the repo, the network, or your secrets: a worktree agent can still read ~/.aws or curl anywhere.

So I only reach for a container/VM the moment an agent runs untrusted code or I care about blast radius — npm install on a sketchy dep, executing model-written shell, anything that could exfiltrate env vars. Rule of thumb: worktree for "don't let agents collide", container for "don't let an agent hurt the host". Most local setups only need the first, and people tend to reach for heavyweight sandboxing before they need it, then abandon it because it's painful.

A cheap middle ground that works locally: worktrees + a per-agent env file and a restricted PATH, so at least secrets aren't ambient without paying full container cost.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.