This breaks the non-interactive mode the post want to achieve. Claude will not be able to install some things and will require user action, which is not desired here.

Like what? It can already use npm/pip/etc. And if it needs a new APT package or config in /etc/ then you would want to know because you need to document it.

Claude Code on NixOS feels like it has super powers. Being able to spin up a nix-shell with needed dependencies on demand gives it access to all sorts of tools I don't have or want installed on my base system. My "book-recommendation" claude code uses sqlite to manage my reading history and to-read and maybe-read lists but I never installed tools for sqlite and they aren't present on my NixOS desktop. It just launches a nix-shell with sqlite anytime it needs to read/modify the database. As long as the database file is within the directory claude code was launched from, it doesn't need to prompt for permission. With the caching that NixOS does, it's fast enough to not even think about.

If you make claude work with c/c++, it may need apt for libraries or build tools.

Even with npm/pip, these may not be available on a base linux box.

Even then, some complex projects may need other tools that are not part of a base system (command line tools, redis, ...).

I tried this approach for a while, but I really wanted it to be able to do anything (install system packages, build/run Docker containers, the works).

With these powers there's a lot less back-and-forth with me running commands, copying the output, pasting it to Claude, etc.

I'm sure you've had the case where you had to instruct someone to do something (e.g. playing tech support with family, helping another engineer, etc). While it helps the other person learn, it feels soooo slow vs just doing it yourself :) And since I don't have to teach the agent, I think this approach makes sense.

I run it with sudo enabled - true story

just give it its own machine and let it check out any code

I PXE boot it from a known image when I feel the need

Running it remotely on a VM seems like a very sensible option. Just don't give it permission to nuke the remote repository hah (EG don't allow force-push, use protected branches, only allow write access to branches it created)

Same solution here - keep a base diskless image on the server, copy it to the diskless area, pxeboot the machine. Works for Windows too (iscsi).

Could do the same thing on EC2 of course.