Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go hard on agents, not on your filesystem

jai.scs.stanford.edu

Post reply on HN
Print view View original

181–190 of 374 posts

Re: Go hard on agents, not on your filesystem

#181

Post by eru »

KronisLV wrote: post #171
eru wrote: post #146

Earlier quoted context omitted.

> It's really surprising they don't just tweak what Claude uses and lock it down to where it cannot be harmful. Ensure it only ever calls tooling Claude Code provides. That would make it far less useful in general.

Maybe Anthropic (or some collection of the large AI orgs, like OpenAI and Anthropic and Google coming together) should apply patches on top of (or fork altogether) the coreutils and whatever you normally get in a userland - a bit like what you get in Git Bash on Windows, just with: 1) more guardrails in place 2) maybe more useful error messages that would help LLMs 3) no friction with needing to get any patches upstr…

So for me, it's really, really useful for Claude to be able to send Slack messages and emails or make pull requests.

But that's also the most damaging actions it could take. Everything on my computer is backed up, but if Claude insults my boss, that would be worse.

Re: Go hard on agents, not on your filesystem

#182

Post by varl »

AnotherGoodName wrote: post #15

Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.

I've had issues with the sandbox feature, both on linux (archlinux) and two macos machines (tahoe). There is an open issue[1] on the claude-code issue tracker for it.

I'm not saying it is broken for everyone, but please do verify it does work before trusting it, by instructing Claude to attempt to read from somewhere it shouldn't be allowed to.

From my side, I confirmed both bubblewrap and seatbelt to work independently, but through claude-code they don't even though claude-code reports them to be active when debugging.

[1] https://github.com/anthropics/claude-code/issues/32226

Re: Go hard on agents, not on your filesystem

#183

Post by mjmas »

user34283 wrote: post #165
globular-toast wrote: post #158

Earlier quoted context omitted.

FOMO is a hell of a thing. Sad though given it would have taken maybe a couple of hours to figure out how to use a sandbox. People can't even wait that long.

Coding agents work just fine without a sandbox. If you do use a sandbox, be prepared to endlessly click "Approve" as the tool struggles to install python packages to the right location.

This also works fine without a sandbox:

  echo -e '#!/bin/sh\nsudo rm -rf/\nexec sudo "$@"' >~/.local/bin/sudo
  chmod +x ~/.local/bin/sudo
Especially since $PATH often includes user-writeable directories.

Re: Go hard on agents, not on your filesystem

#184

Post by jon-wood »

safety1st wrote: post #149
PaulDavisThe1st wrote: post #60

Earlier quoted context omitted.

On Linux, chroot(2) is hard to escape and would apply to all child processes without modification.

We anthropomorphize these agents in every other way. Why aren't we using plain ol' unix user accounts to sandbox them? They look a lot like daemons to me, they're a program that you want hanging around ready to respond, and maybe act autonomously through cron jobs are similar. You want to assign any number of permissions to them, you don't want them to have access to root or necessarily any of your personal files. It…

Oh that’s an idea. I was going to argue that it’s a problem that you might want multiple instances in different contexts but sandboxing processes (possibly instanced) is exactly what systemd units are designed to deal with.

Re: Go hard on agents, not on your filesystem

#185

Post by throwaway2027 »

giancarlostoro wrote: post #95
mazieres wrote: post #57

Earlier quoted context omitted.

I've seen claude get confused about what directory it's in. And of course I've seen claude run rm -rf *. Fortunately not both at the same time for me, but not hard to imagine. The claude sandbox is a good idea, but to be effective it would need to be implemented at a very low level and enforced on all programs that claude launches. Also, claude itself is an enormous program that is mostly developed by AI. So to have…

In my opinion Claude should be shipped by a custom implementation of "rm" that Anthropic can add guardrails to. Same with "find" surprised they don't just embed ripgrep (what VS Code does). It's really surprising they don't just tweak what Claude uses and lock it down to where it cannot be harmful. Ensure it only ever calls tooling Claude Code provides.

All of which is useless when it just starts using big blocks of python instead. You need filesystem sandboxing for the python interpreter too.

Re: Go hard on agents, not on your filesystem

#186

Post by fc417fc802 »

tokioyoyo wrote: post #102
fc417fc802 wrote: post #79

Earlier quoted context omitted.

People were also dismissing concerns about build tooling automatically pulling in an entire swarm of dependencies and now here we are in the middle of a repetitive string of high profile developer supply chain compromises. Short term thinking seems to dominate even groups of people that are objectively smarter and better educated than average.

> “high profile developer supply chain compromises” And nothing big has happened despite all the risks and problems that came up with it. People keep chasing speed and convenience, because most things don’t even last long enough to ever see a problem.

I've yet to be saved by an airbag or seatbelt. Is that justification to stop using them? How near a miss must we have (and how many) before you would feel that certain practices surrounding dependencies are inadvisable?

A number of these supply chain compromises had incredibly high stakes and were seemingly only noticed before paying off by lucky coincidence.

Re: Go hard on agents, not on your filesystem

#187

Post by globular-toast »

user34283 wrote: post #165
globular-toast wrote: post #158

Earlier quoted context omitted.

FOMO is a hell of a thing. Sad though given it would have taken maybe a couple of hours to figure out how to use a sandbox. People can't even wait that long.

Coding agents work just fine without a sandbox. If you do use a sandbox, be prepared to endlessly click "Approve" as the tool struggles to install python packages to the right location.

Erm, no, that's not a sandbox, it's an annoyance that just makes you click "yes" before you thoughtlessly extend the boundaries.

A real sandbox doesn't even give the software inside an option to extend it. You build the sandbox knowing exactly what you need because you understand what you're doing, being a software developer and all.

Re: Go hard on agents, not on your filesystem

#188

Post by vorticalbox »

lemontheme wrote: post #164

And for the macos users, I can’t recommend nono enough. (Paying it forward, since it was here on HN that I learned about it.) Good DX, straightforward permissions system, starts up instantly. Just remember to disable CC’s auto-updater if that’s what you’re using. My sandbox ranking: nono > lima > containers.

I’m using safe house [0] its a bash wrapper around sandbox-exec

0 https://agent-safehouse.dev/

Re: Go hard on agents, not on your filesystem

#189

Post by kstenerud »

rsyring wrote: post #64
mazieres wrote: post #48

Earlier quoted context omitted.

It's a good point. Maybe I should add an option to make certain directories read-only even under the current working directory, so that you can make .git/ read-only without moving it out of the project directory. You can already make CWD an overlay with "jai -D". The tricky part is how to merge the changes back into your main working directory.

It's great that you have -D built into the tool already. That's a step in the right direction. I don't think the file sync is actually that hard. Famous last words though. :)

Not famous last words ;-)

I've already shipped this and use it myself every day. I'm the author of yoloAI (https://github.com/kstenerud/yoloai), which is built around exactly this model.

The agent runs inside a Docker container or containerd vm (or seatbelt container or Tart vm on mac), against a full copy of your project directory. When it's done, `yoloai diff` gives you a unified diff of everything it changed. `yoloai apply` lands it. `yoloai reset` throws it away so you can make the agent try again. The copy lives in the sandbox, so your working tree is untouched until you explicitly say so.

The merge step turned out to be straightforward: just use git under the hood. The harder parts were: (a) making it fast enough that the copy doesn't add annoying startup overhead, (b) handling the .pyc/.venv/.git/hooks concern you raised (they're excluded from the diff surface by default), and (c) credential injection so the agent can actually reach its API without you mounting your whole home dir.

Leveraging existing tech is where it's at. Each does one thing and does it well. Network isolation is done via iptables in Docker, for example.

Still early/beta but it's working. Happy to compare notes if you're building something similar.

Re: Go hard on agents, not on your filesystem

#190

Post by ethanwillis »

throwaway2027 wrote: post #185
giancarlostoro wrote: post #95

Earlier quoted context omitted.

In my opinion Claude should be shipped by a custom implementation of "rm" that Anthropic can add guardrails to. Same with "find" surprised they don't just embed ripgrep (what VS Code does). It's really surprising they don't just tweak what Claude uses and lock it down to where it cannot be harmful. Ensure it only ever calls tooling Claude Code provides.

All of which is useless when it just starts using big blocks of python instead. You need filesystem sandboxing for the python interpreter too.

What we need is a capabilities based security system. It could write all the python, asm, whatever it wants and it wouldn't matter at all if it was never given a reference to use something it shouldn't.
Post reply on HN