Comment by mjd

1 month ago

A few months ago I noticed that even without `--dangerously-skip-permissions`, when Claude thought it was restricting itself to directory D, it was still happy to operate on file `D/../../../../etc/passwd`.

That was the last time I ran Claude Code outside of a Docker container.

It will happily run bash commands, which expands it's reach pretty widely. It's not limited to file operations, and can run system wide commands with your user permissions.

  • Seems like the best way to limit its ability to destroy things is to run it as a separate user without sudo capabilities if the job allows.

    That said running basic shell commands seems like the absolute dumbest way to spend tokens. How much time are you really saving?

You don't even need a container. Make claude a local user. Without sudo permission. It will be confined to damaging its own home directory only.

  • The problem is, container (or immutable) based development environment, like DevContainers and Nix Flakes, still aren't the popular choice for most developments.

    I self-hosted DevPods and Coder, but it is quite tedious to do so. I'm experimenting with Eclipse Che now, I'm quite satisfied with it, except it is hard to setup (you need a K8S cluster attached to a OIDC endpoint for authentication and authorization, and a git forge for credentials), and the fact that I cannot run real web-version of VSCode (it looks like VSCode but IIRC it is a Monaco fork that looks almost like VSCode one-to-one but not exactly it) and most extensions on it (and thus limited to OpenVSIX) is a dealbreaker. But in exchange I have a pure K8S based development lifecycle, all my dev environment lives on K8S (including temporary port forwarding -- I have wildcard DNS setup for that), so all my work lives on K8S.

    Maybe I could combine a few more open source projects together to make a product.

    • Uhm, pardon my ignorance... but wouldn't restricting an AI agent in a development environment be just a matter of a well-placed systemd-nspawn call?...

      3 replies →