bsd is super easy for this kind of setup tbh. Sylve or Bastille is amazing for it. 1 liner jails setups etc. its real quick and efficient. depending on flavor u can also use pledge/unveil or capsicum or whatever to lock things down even more.
Slightly safer vibecoding by adopting old hacker habits
41–50 of 110 posts
Re: Slightly safer vibecoding by adopting old hacker habits
#42The fact that Claude can and does access files outside the PWD while asking for sudo to do things constantly seems to be a recipe for Anthropic scanning your system without your knowledge and saving that for 5 years if you decided to 'help improve Claude'.
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.
Re: Slightly safer vibecoding by adopting old hacker habits
#43I 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 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.
Re: Slightly safer vibecoding by adopting old hacker habits
#44I've been doing something similar by letting Claude run in a Virtualbox VM. It's easy to use, no issues with observability, and the attack & damage surface is far less of an issue.
Re: Slightly safer vibecoding by adopting old hacker habits
#45I use a separate user account per project on my local machine (not in sudoers), which I ssh to, and also runs tmux. If I need claude code in windows, then I run a VM. The performance and (in)convenience cost of this to me is minimal. I started working this way in order to limit the "blast radius" when claude went on a dependency binge within a project.
Re: Slightly safer vibecoding by adopting old hacker habits
#46Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology mixup from the way github presents forks and clones.
I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can…
Maybe this is doable with scoped API keys instead of SSH keys?
Re: Slightly safer vibecoding by adopting old hacker habits
#47IM new to Claude code but doesnt auth require a gui browser to authenticate the Claude session first time login?? Do you have to setup a desktop environment just for that?
You can run all the major CLI tools without a browser.
When they try to open a browser, they also print the URL to the console. Open that in your browser and go through an authentication flow; it'll end forwarding you to a localhost URL like http://127.0.0.1:8080/authorization-code/callback?code=XXXX&... which will fail.
Copy that callback URL, connect to your VM/docker container, and curl it.
The curl stage requires the agent make a call to auth.whatever-vendor.com so if it fails at this stage, check your VM/container network settings. And make sure you quoted the curl right so the & wasn't misinterpreted.
It'll then save a file at ~/.codex/auth.json or ~/.claude.json or similar, so you won't need to log in again. The secret in this file will periodically rotate, so you need to mount it read-write not read-only.
Re: Slightly safer vibecoding by adopting old hacker habits
#48The fact that Claude can and does access files outside the PWD while asking for sudo to do things constantly seems to be a recipe for Anthropic scanning your system without your knowledge and saving that for 5 years if you decided to 'help improve Claude'. 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 m…
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 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.
It's really like some "agent" (yeah I know, but I mean really an external person) takes control of your computer, with the same privileges as you. Idk why I had to see this happen in front of my eyes to fully realize this.
Of course every computer program has these rights, and you have to trust any of these devs...
Re: Slightly safer vibecoding by adopting old hacker habits
#49I 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…
Yeah, it's easy to vibecode and review a docker sandbox, too. If you run containers with
--runtime=runsc
--cap-drop=ALL
--security-opt no-new-privileges:true
Re: Slightly safer vibecoding by adopting old hacker habits
#50IM new to Claude code but doesnt auth require a gui browser to authenticate the Claude session first time login?? Do you have to setup a desktop environment just for that?
https://gitlab.com/grepular/claude-sandbox runs claude in a podman container. The way it deals with this is:
claude-cli executes whatever is in the BROWSER env variable to open your browser at a current URL, so I pointed it at a simple shell script that writes the URL to a named pipe which is mounted into the container. The sandbox tool outside of the container is reading from that named pipe. When it receives a URL to open, it pops up a confirmation dialog with info about the URL. If you accept, it opens it in your host browser.
The second step is, the callback URL after you sign in on the claude website wants to connect back to a port on localhost to complete the sign in. If the sandbox is being run with host networking mode, this just works fine as claude cli has already opened that port so it's listening on the host network. However if it is not running in host networking mode, the sandbox tool figures out what port it need to listen on from looking at the URL, listens to it, and when it is hit, it just podman exec's curl inside the container to complete the callback.