Hacker News Reader

Gonna take this opportunity to get some feedback. I never figured out containers (one of these days..!), but I didn't want to yolo AI agents on my machine.

At some point I realized, what I'm actually worried about is it blowing up my files. So I just made a separate linux agent "agent", and put myself in the agent group.

So I can read/write the agent homedir, but agents cannot read/write mine.

So now I just switch to agent user before running Claude, Codex, OpenClaw etc.

I'm not a security expert -- seems there are still some suboptimal aspects to this (e.g. /tmp is globally readable?), but it seems good enough for the main vector to me? ("Claude Code deleted my homedir/hard drive" that pops up every few weeks on Reddit...)

(If someone gets a remote shell via an exploit in a certain bloated agent framework that's a slightly different story though ;)

But I was wondering what you all think about that. "Just give it a Linux user." It doesn't seem to be a common approach, though I've seen a few other people doing it. I wonder if I'm missing something, or if it's actually a good solution but boring and non-obvious to most people.

(Tangential but I do find it pretty funny when people spend 3 hours hardening OpenClaw inside Docker inside a VM inside a locked down VPS and then they just hook it up directly to their GMail account)

As a side note the agents are getting scary good with their persistence and determination. Claude and Codex bypassing security restrictions without a second thought, just to complete a task...

https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_...

I had a similar experience with Codex... "the instructions forbid me from deleting the remote branch, so I will find a creative workaround to achieve the same result..." Following the letter of the law, but not the spirit! They're already acting a lot like the paperclip maximizer, which is... something to think about...

I guess one way to answer my own question would be to ask them to bypass the user permissions somehow! I'm slightly afraid to run that experiment...

View on HN

FROM python:3-alpine WORKDIR /my_app RUN pip install flask # copy app.py from the working directory to the container directory "." COPY app.py . # Make port 5000 available to the world outside this container # this networking stuff is a bit of a mess to configure, you have to set it in flask, the Dockerfile, when you run the container, and you still get different URLs that the server is on, not all work on the host or the container, etc., it's a bit of a mess IMO. This turned out to not be necessary. #EXPOSE 5000 # Define environment variable for Flask ENV FLASK_APP=app.py ENV FLASK_RUN_HOST=0.0.0.0 # run the command "flask" when the container starts with the "run" argument CMD ["flask", "run"]