[felixyz]

You have to be extremely careful when you set up a dev container, lock down file access, do not give the agent the power to start other containers or "docker compose up", restrict network access to an allow-list etc. Just running the agent in a container does little to protect you. (Maybe you know this, but a lot of people don't!)

[embedding-shape]

Most of those things are what happens by default. Sure, be careful, but by default it's secure enough to prevent most potential issues. No need to lock down file access for example, by default it only has access to files inside the container, and of course by default containers don't have access to start other containers, and so on.

Good word of caution though, make sure you actually isolate when you set out to isolate something :)

[chrisweekly]

I've just discovered and started using smolmachines^1 which actually have the requisite isolation.

1. https://smolmachines.com

[embedding-shape]

As mentioned, "podman/docker run -it $my-image codex" also actually has the requisite isolation by default, no need for special software. Biggest risk is accidental deletion of stuff, easily solved without running an entire VM, which "smol" machines seems to be. No doubt VMs have their uses too, but for simple isolation like this I personally rather use already existing tooling.

[chrisweekly]

Ok, YMMV, but a smolvm provides macOS-native, per-workload isolation -- vs trad container depending on a daemon and relying on namespaces (w/ a shared kernel). Easy "packing" into single-file executables, and a nice SDK, make it ~ideal for my needs; great balance of security:convenience.

https://smolmachines.com/#comparison

[embedding-shape]

Cool ad bro, but stop claiming container won't get you "per workload isolation" just because they share kernels, in the context of this discussion it hardly matters, containers isolates enough for this.

[chrisweekly]

ad? I have no affiliation w smolmachines, just glad I found it.