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.
Go hard on agents, not on your filesystem
351–360 of 374 posts
Re: Go hard on agents, not on your filesystem
#352Earlier 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…
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[flagged]
Re: Go hard on agents, not on your filesystem
#354Docker 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.
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
#355I'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…
Re: Go hard on agents, not on your filesystem
#356Earlier 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.
Re: Go hard on agents, not on your filesystem
#357It'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 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
#358Earlier 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…
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
#359Earlier 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…
Almost like it doesn't understand the purpose of the sandbox.
Re: Go hard on agents, not on your filesystem
#360Add 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.
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