Are you doing something more advanced with Podman than just mounting the files? How is the access for relevant files given? How is the authentication shared across multiple uses? Just curious to streamline the process.

▲

lobo_tuerto 7 hours ago | parent | next [-]

Just a little bit, I want coding agents to work their own disposable copy of a git repo. Here is a quick rundown of what it does:

It copies the current Git repo into the sandboxes dir, mounts that copy at /workspace in the container. The original repo is never mounted writable, so I don't care if the agent goes to town/wild in there (peace of mind).

It also builds cached Debian/mise/Elixir/Phoenix images, can start a private Postgres container, publishes selected localhost ports, reuses dependency/build caches, and prints commands on exit for reviewing diffs, exporting patches, applying them back to the real repo, or reopening the same sandbox later. Pi, and OpenCode are configured with proper LLM access keys (derived from my own).

So spinning a new sandbox is a matter of cding into a project directory and run something like: `ai-sandbox --port 4000 --postgres somedbname` or `ai-sandbox --port 4001` if I don't need DB support. Then when running the server in the container I can access it from the host machine to review in my browser.

▲

mixedbit 8 hours ago | parent | prev [-]

I work on a sandbox which has similar isolation level to Podman (rootless Linux user namespaces), but with UX optimized for local development work. Take a look: https://github.com/wrr/drop Basically, you don't enter a separate container in which you install a new distro, but you run on top of your current distro. You have environment specific home dirs which isolate your original home, but can have some files, such as configs, mounted from your original home (mostly in read-only mode).

▲

drannex 7 hours ago | parent [-]

This is wonderful - might even be exactly what one of my projects needs to use as a dependency.

In the README it mentions that it puts the dev environment in a filesystem jail, but how are you able to use your hosts bins without leaking access to the rest of the system? Or is that just an assumed liability?

	▲	mixedbit 7 hours ago \| parent [-]
		It assembles and pivots to own root filesystem. The filesystem mounts dirs and files from your original filesystem, most of them in read-only mode, but does not mount files that expose secrets to the sandbox. The sandbox also mounts own, writable version of your home dir, so secrets, such as .ssh dir are not exposed. The config file allows to configure which files should be exposed from your original home. For example, configs, such as .bashrc, are safe to expose in read-only mode, provided you don't store secrets in them.