91–100 of 110 posts
People seem to come up with all manner of complicated setups with virtual machines or docker or whatever. All you need is a separate limited user account on your computer. Multi-user Unix-y systems were designed for this kind of thing for decades. My entire development environment is literally just "sudo".
I use my personal laptop for $WORK and everything work related is done via the VM.
This works well for vibecoding on a codebase in isolation, which to be fair is what the author is addressing. I don’t think it solves the problems at the current frontier of agent use though, where you expose internal infrastructure via tools to make the agent maximally productive. How to do this safely is still unsolved
People seem to come up with all manner of complicated setups with virtual machines or docker or whatever. All you need is a separate limited user account on your computer. Multi-user Unix-y systems were designed for this kind of thing for decades. My entire development environment is literally just "sudo".
The advantage of VMs is that you can nuke them and be done with it if you need to. I use my personal laptop for $WORK and everything work related is done via the VM.
I remember someone on HN once saying they treat LLM agents like human coworkers, security-wise, and that stuck with me. 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 stil…
Earlier quoted context omitted.
Some weeks ago I opened Zeditor, it asks me if I want AI, I say yes, a sidebar opens I ask said LLM: What can you see? It does some `ls`'s, it sees my .ssh folder and priv keys. I turned it off. Now I run Claude code in a container with just pwd mounted to it. The whole experience was a bit jarring. When it knows I use nix, the the thing can easily `nix-shell -p nmap` its way into learning a lot more about my entire…
> The whole experience was a bit jarring. When it knows I use nix, the the thing can easily `nix-shell -p nmap` its way into learning a lot more about my entire network than I am comfortable with. I think I'll edit the Containerfile further to also make Claude Code a user that can't install anything. Note that putting it in container changes jack shit, if it still has network access, it can scan your network anyway,…
That's why VLANs are nice, as is requiring your container system (or VM or whatever) to attach its vNICs to a VLAN-tagged bridge on the host rather than the untagged interface that your trusted software uses. If the only thing that the container can hit on your LAN is your router, and your router refuses to forward traffic from that untrusted VLAN to anywhere other than the internet, then that cuts off another avenue for intelligence gathering.
That all assumes that you can't exploit the container daemon to get root, of course.
Earlier quoted context omitted.
> The whole experience was a bit jarring. When it knows I use nix, the the thing can easily `nix-shell -p nmap` its way into learning a lot more about my entire network than I am comfortable with. I think I'll edit the Containerfile further to also make Claude Code a user that can't install anything. Note that putting it in container changes jack shit, if it still has network access, it can scan your network anyway,…
Every goddamn time with this type of dogshit advice. Perfect is the enemy of good. Don't just rawdog a coding agent because a perfectly viable solution (containers) takes an hour or two of work to set up. There's a world of difference between "it can scan your network" and "I just uploaded my private SSH keys to the cloud".
Setting up a separate unprivileged Linux user account takes all of like a minute. Assuming that the $HOME for your daily-driver account isn't world-readable, [0] that gets you the majority of the isolation that containerization provides and doesn't expose you to any bugs in the containerization management daemon (or the containerization code, itself) that may still be present even after all these years.
These things are usually TUIs or CLIs, so you don't need to bother with giving them xauth access or whatever the Wayland equivalents for that are.
[0] If it is, you might consider fixing that immediately.
I would guess OpenAI Codex and Claude Code are well into the millions subscriber range at this point. I would venture to guess the majority of them run in yolo mode. I have only seen a few horror stories on reddit. The same way any time you drive a car you can crash and die (many times through no fault of your own). All that said, no way in hell I’m giving either access to production databases or environments.
Codex 5.4 medium couldn’t figure out how to run tests in my staging Cloudflare so it went ahead and ran those tests against prod. Mission accomplished. Yes, agents.md yells not to mess with prod.
Probably what nudged it to run on prod in the first place
I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist. 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 launch…
Has anyone figured out a good way to use (neo)vim with devcontainers?
It sounds like if you make devcontainers point at an existing Dockerfile it should be easy to make these work together, so you and teammates both use the same configuration. I haven't used devcontainers though.
I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist. 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 launch…
I used to use sealtbelts for sandbox, i found it consumes way more tokens when sandboxed. Now, i run YOLO and haven't had any issue and my subscription lasts much longer with less token consumption!
> The actual development happens on a rented server
Why not Hyper-V or libvirt/KVM? VM escapes aren't a thing in real life (or VMs from hyperscalers wouldn't exist), so why deal with additional cost, latency, and third-party trust when you could just run it yourself?