In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launches a remote frontend connected to that container (which may run on the same or a different machine from where the frontend runs).

If you do anything with an AI agent, that thing happens inside the remote container where the project code files are. If you compile anything, or run anything, that happens in the container too. The project directory itself is synced back to your local system but your home directory (and all its credentials) are off-limits to things inside the container.

It's actually easier to do this than to not, since it provides reusable developer tooling that can be shared among all team members, and gives you consistent dependency versions used for local compilation/profiling/debugging/whatever.

DevContainers are supported by a number of IDEs including VSCode.

You should be using them for non-vibe projects. You should DEFINITELY be using them for vibe projects.

The downside for me and the main reason I do use vms less than I did a few months ago is that I need my agentic coding tools to use development tools a lot. And those tools need a lot of resources. And I have those resources on my laptop. Which is a nice mac book pro with plenty of RAM and 16 CPUs. I can run vms on this thing without issues of course. But tools just run a lot faster when I run them outside those VMs. And agentic coding tools run builds all the time. We're talking some really non trivial time savings here. Watching qemu build a thing for 10 minutes that I know should build in 45 seconds is painful. Especially if it happens over and over again.

The trick is doing sandboxing without performance impact. And very soon you'll also want to be able to run local models. I've been toying with the latest qwen and gemma models on my laptop. I haven't gotten around to doing coding with those just yet. But apparently they aren't completely horrible at it. That won't work on most cloud based vms. Unless you get a really big and expensive one. You could actually make that work if you only use them for a few minutes.

No, 'safety oriented' lab has a clause like that which can't be revoked historically. Anthropic, like the majority of 'don't be evil' firms is apart of the great masquerade.

All that said, no way in hell I’m giving either access to production databases or environments.

You don't give your GH keys, email credentials and ssh keys to a coworker. They have their own accounts with scoped permissions. Need them to read an email? Forward it. Need them to work on a repo? Add them as a contributor and enforce the same branch policies you would for any human.

There are still risks, but they're similar to delegating work to humans, so it's up to you how much access and trust to give.

Almost back to point A then. If the server is compromised in some way, they can use (not copy) OP's keys and use them to clone repos/inject code/etc..

    # Create a new sandbox copying . as workdir (default container, but you can choose vm)
    yoloai new mybugfix . --isolation vm

    # attach to it (it has tmux already)
    yoloai attach mybugfix

    # Chat with the bot inside...

    # Happy with its work? Diff it to be sure
    yoloai diff mybugfix

    # Happy with the changes? Apply them to your workdir
    yoloai apply mybugfix

    # All done? Destroy the sandbox
    yoloai destroy mybugfix

https://github.com/kstenerud/yoloai

- user and home directory for data

- crontab for scheduled jobs

- cgi for serving user space apps

- rsync for backups

We even rediscovered email patches but with agent to agent help making and applying them.

It’s simpler for us to operate and the agent to figure out.

Treat it as a colleague, making PRs that you review.

Gotta love how someone downvoted this.