Live data from Hacker News

Go hard on agents, not on your filesystem

jai.scs.stanford.edu

351–360 of 374 posts

Re: Go hard on agents, not on your filesystem

#351

Earlier quoted context omitted.

Oh, rm failed, since we're running in a weird environment! Let me retry with `bash -c "/usr/bin/rm -rf *"`!

Ideally they control the harness and should be able to stop Claude from running any shell willy nilly.

Thus defeating the purpose of a custom "rm"

Re: Go hard on agents, not on your filesystem

#352
post #349

Earlier quoted context omitted.

> You need to rewrite No they don't. The text is very clearly conveying what this project is about. Not everyone needs to cater to weirdos who are obsessed with policing how other people use LLM.

The people who don't care about LLM slop being shoved down their throat at every turn are the "weirdos" here. The project might not be slop, but the website certainly is, and it's perfectly reasonable for people to stop reading immediately and decide that they don't care about what could be an otherwise useful project when they determine that the author didn't give enough of a shit to even write the text on the websi…

But there is an old-school README.me at the github homepage: https://github.com/stanford-scs/jai The repository has an old-school ASCII INSTALL file.

If you don't like the vitepress site, just use github and read the human-written README and man page there. All the information you need to use the software is available without laying eyes on any AI slop. Of cource, if you hate AI so much that you can't get past a vibe-coded landing page, you might not be the target audience for jai, because you probably aren't doing a lot of vibe coding. But maybe jai is still useful to you for grading programming assignments or running installer scripts.

Re: Go hard on agents, not on your filesystem

#353
post #324

[flagged]

jai uses persistent file systems for your changes (except for `/tmp`, `/var/tmp` and `/run/user`, which usually aren't persistent anyway). The data is stored under `$HOME/.jai` by default. But you can also expose specific directories to persist state in your home directory like `jai -d ~/.codex`, which would then survive even if you manually deleted your whole `~/.jai` directory.

Re: Go hard on agents, not on your filesystem

#354

Docker is hard to setup. The author made a nice solution but not sure if he know devcontainer and what he can do. You do the setup once and you roll in most dev tools. I'm still surprised the effort people put in such solution ignore the dev's core requirements, like sharing the env they use in a simple way. You used it to have custom env and isolate the agent. You want to persist your credentials? Mount the target f…

I'm surprised from reading these comments that more people aren't chiming in to ask why this solution is better than a dev container. That seems like the obviously best way to setup security boundaries that don't require you to still trust that AI will do what you ask it. You can run it remotely and it's portable etc.

Please use a dev container! Empirically, a lot of people don't, and some people regularly enable YOLO mode on their actual laptops. So if you've never run a code assistant outside of a dev container, that's fantastic and I don't want to change your behavior. But be honest with yourself--if you aren't 100% consistent about using a container, then jai may be for you, because it just works in every single scenario.

I can honestly say that since developing jai, I haven't run an assistant outside of a container. In fact, I now only have the assistants installed inside containers, so if I run `claude`, command not found, it has to be `jai claude`. The only place I have to run outside of jai is for testing jai itself, for which I use a virtual machine and just let the assistant have root, but that's a heavyweight environment I'm forced to use for this particular problem domain.

Re: Go hard on agents, not on your filesystem

#355

I've been running GPT5.x fully unconstrained with effective local admin shell for over $500 worth of API tokens. Not once has it done something I'd consider "naughty". It has left my project in a complete mess, but never my entire computer. git reset --hard && git clean -fd That's all it takes. I think this is turning into a good example of security theatrics. If the agent was actually as nefarious as the marketing h…

An AI agent that works 99.9% of the time is a lot more dangerous than one that works 90% of the time, because the former leads to expectations of 100% safe behavior. I've never been saved from harm by a car seatbelt. Should I extrapolate that vehicles are basically safe and seatbelts are safety theater?

Re: Go hard on agents, not on your filesystem

#356

Earlier quoted context omitted.

Not sure about OPs impl, but the wording doesn’t matter. The hook prevents the use of whatever action you want. Eg it’s impossible for Claude to use Emojis for me. My hook doesn’t allow it. So it’s deterministic based upon however the script it written

If your hook prevents rm, it is possible for Claude to write a script that does the rm and execute the script.

Yup, that's totally possible, but you still have to approve the script. But that's a bit of a moot point right? Claude is writing code, nearly anything is possible with code, ergo claude could do anything lol.

Re: Go hard on agents, not on your filesystem

#357
post #104

It's full VM or nothing. I want AI to have full and unrestricted access to the OS. I don't want to babysit it and approve every command. Everything that is on that VM is a fair game and the VM image is backed up regularly from outside. This is the only way.

I have a pretty insane thing where I patched the screen sharing binary and hand rolled a dummy MDN so I can have multiple profiles logged in at once on my Mac Studio. Then have screen share of diff profiles in diff "windows". Was for some ML data gathering / CV training. It's pretty neat, screen sharing app is extremely high quality these days, I can barely notice a diff unless watching video. Almost feels like Firef…

> I have a pretty insane thing where I patched the screen sharing binary and hand rolled a dummy MDN so I can have multiple profiles logged in at once on my Mac Studio

I have a Studio collecting dust that I've been eyeing every time my VM crashed because of Apple's paravirtualized GPU proxy not being able to keep up with things I run in it.

This sounds exactly like what I wanted to do on my Studio and didn't know where to pull the thread from.

Do you have this method shared openly anywhere?

Re: Go hard on agents, not on your filesystem

#358
post #290

Earlier quoted context omitted.

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…

I tried this with Claude code on macOS. I created a new agent user and a wrapper do run Claude has that user, along with some scripts to set permissions and ownership so that I could run simple allow/deny commands. The only problem was that the fancy oauth flow broke. I filed an issue with Anthropic and their ticket bot auto closed it “for lack of interest” or whatever. I fiddled with transferring the saved token fro…

Someone tried this earlier this year but they ended up going with bubblewrap (what Anthropic uses for the sandbox). Here's the blog if you're interested. https://patrickmccanna.net/a-better-way-to-limit-claude-code...

I ended up creating an LXC on my homelab and providing it access there, with a self-hosted gitea server but that's only for side projects that I want to host, not develop actively.

Re: Go hard on agents, not on your filesystem

#359
post #46
post #28

Earlier quoted context omitted.

Is this a real sandbox or just a pretty please?

By default it will automatically retry many tool calls that fail due to the sandbox with the sandbox disabled. In other words it can and will leave the sandbox. For example: Bash(swift build 2>&1 | tail -20) ⎿ warning: /Users/enduser/Library/org.swift.swiftpm/configuration is not accessible or not writable, disabling user-level cache features. warning: /Users/enduser/Library/org.swift.swiftpm/security is not accessib…

I think this part can be improved. When it knows it's blocked by sandbox, it shouldn't try to circumvent it. I've had it download programs when it's blocked from using something and it's super annoying.

Almost like it doesn't understand the purpose of the sandbox.

Re: Go hard on agents, not on your filesystem

#360

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.

For some reason, this made everything worse for me. Now claude constantly tries to access my home folder instead of current directory. Obviously this is not still good enough. Also Claude keeps dismissing my instructions on not to read my home directory and use current directory. Weird.

I have the same problem. If my sandbox includes `denyRead: ["~"]`, claude consistently tries to do things inside my home directory. For example, every time I start claude I tell it to "run pwd".

And every time it says this:

    Bash(pwd)  
      ⎿  /home/  
      ⎿  Shell cwd was reset to /home//Projects/
This breaks a bunch of features in inconsistent ways (e.g., `git status` sometimes works and sometimes doesn't).

There are issues reporting this problem to Anthropic but they are all closed with no helpful comments:

https://github.com/anthropics/claude-code/issues/11067

https://github.com/anthropics/claude-code/issues/17053

https://github.com/anthropics/claude-code/issues/27255

Post reply on HN