upvote
YOLO.

Btw for real tho, if you don't have the time or means to mess with full sandboxed environments, just working within a git repo and instructing on your agents.md project level that the agent should back up dirty files (local changes that were not yet committed) before changing them is enough and super fast and easy to set up. And by back up I just mean a simple instruction to back up to some temp location under random named, but rembered during one "turn" of agent thinking, subfolder ( .../temp/{random}/orginal/tree/file.xyz )

This is so the agent (or you later) can recover even locally changed files if it messes them up for whatever reason.

As for the rest you gotta watch what you're asking for, but generally speaking, these SOTA models are smart, none of them will just delete your stuff even with full access. I've been raw dogging multiple projects on my work machine with zero issues of this kind for months. I created codex_reader read only acccounts for my local databases and just add that to agents.md with a note its allowed to only use that and never had a problem.

reply
I literally have had a SOTA Codex agent delete a bunch of files just last month, but it took very specific circumstances. It was working within my game repo, in a branch, and it ran out of SSD. It had to free up some space to work, so it looked around and found 25GB of untracked files in the project, in a folder called Recordings. Might as well clean that up, it thinks. There goes all the raw Unity Recorder footage I'd ever recorded of my game, over many years of development.

So yeah, it won't go on a spree outside of its lane even with full access, but if you give it a box and tell it to go ham, it's on you to make sure you didn't leave precious unrecoverable assets in that box.

reply
I run codex in a dedicated vm, I have a cronjob which resets it to clean installed state every week. Nothing too fancy just bhyve and debian, 8gb mem. It has root access there, can install stuff, no permissions to push to protected branches etc. It didn't take very long to setup, and I can sleep a bit better...
reply
I use the auto-reviewer for actions outside the builtin sandbox.

So far this has been rock solid, and tens of millions of developers use this setup without issue.

It is not going to wipe our hard disks. At least I hope so. Fable and GPT 5.6 have been ever more proactive, and GPT 5.6 is automating the AppStore on my machine to download an Xcode update while I am typing this.

reply
Is this auto-reviewer part of Codex? Is the review done by the agent or the model?
reply
Yes. In Codex it is called 'Approve for me', in Claude it is 'Auto mode'.

I believe in both cases it is prompting a model with a fresh context that is tasked with reviewing the reason for the action.

With Claude, I have seen that if the reviewer does reject the proposed action, it responds with a long text about how the Agent should not try to work around this rejection, and instead prompt the user for an explicit approval of the proposed action.

reply
Typically I just want to isolate the agent disallowing it from accessing other parts of the filesystem. Using a different user might be enough, but I typically use [bubblewrap](https://github.com/containers/bubblewrap).
reply
deleted
reply
I live in fear lol.

More seriously, I was blindly trusting the auto-classifier from claude code (same as the middle option when you do `/permissions` in codex), and it actually allowed the agent to do pretty hardcore `rm` and `git push --force-with-lease` commands, which I would have expected to have to approve manually. Luckily no major issue from those yet.

The best option imo is the integrated cloud environments from claude code (not sure yet if there's a codex equivalent). It spawns a VM in the cloud where the agent runs, and you can open a PR from the app when it's done. Very smooth experience

reply
Interesting - I'd never heard of this Claude Code VM option.

Does it auto install all the dev/test tools it needs, maybe including things like web server & browser? Does your code live in the VM, or in some external repository? Is the lifetime of the VM the same as the agent, or does it persist until you remove it?

Where can I find documentation on this?

reply
I use it for basic web stuff so haven't pushed it to the limit, but they have tons of stuff you can configure (up to self-hosting your environments): https://platform.claude.com/docs/en/managed-agents/environme...
reply
I still just explicitly approve all actions and review all code (unless it's a personal/throwaway project no one else will ever touch/use/see). I know a lot of people that run in a sandbox though. That said, I'm sure there are lots of people that just yolo it and hope for the best.
reply
What destructive actions are you afraid of in particular? Honestly the models are pretty smart, I let the agents go --yolo and nothing bad has ever happened (yet) that couldn't be solved with git.
reply
I'm not concerned about the code it's working on, but rather anything else - modifying files outside of the project dir (e.g. incorrect tool call), modifying system configuration, doing something bad on the internet, etc.
reply
It is a valid concern but I've been running yolo mode since the inception, using Claude and now Codex. I'm not bragging or anything, since I'm feeding my own curiosity too, trying to answer what's the worst that could've happened? So far, nothing catastrophic that I recall.
reply
deleted
reply
Don't let it outside the sandbox. Don't let it have access to anything but dev environments. Continue using git.

Never had any issues.

reply
Which agent/sandbox are you referring to?
reply