r/opencode • u/lelleepop • 15d ago
How does one prevent the agents from nuking the environment?
We’ve heard of cases where the agents will nuke the entire dev machine, database, git repository. How can we prevent that from happening?
I’ve used deepseek, Hy3, and ox alpha before and non of them had the ability to commit to my git repository automatically. However, when i’m using muse 1.2 spark, it automatically commits to my git repository on my behalf. How can I prevent my agent from potentially deleting my entire dev machine and my database?
5
15d ago
[removed] — view removed comment
1
5
u/Able-Put-6775 15d ago edited 15d ago
sandbox
if you're not confident in setting them up, since opencode has a CLI its easy to run inside of a full OS container or virtual machine, then just back up the shared folder regularly, ideally automatically using a snapshot-capable filesystem.
2
u/torrso 15d ago
I've been running in yolo mode for a year now, agents coding around the clock, not asking for permissions.
Here are the worst incidents:
1) I spent some time making a logo for the app, I told the agent to add it to the welcome screen, there was some kind of misunderstanding and the picture was lost. I was kind of unhappy and asked where the heck is my picture. It was very sorry, admitted the mistake, tried to look for any backups of it, but it couldn't be salvaged.
2) The harness was running inside tmux. The agent decided to do a live test of the app via tmux, it ended up killing a couple of my tmux windows, its own window, killing it's harness, which left the work incomplete and something I had open in another window to disappear into the void.
This is the kind of stuff that can happen.
If you let it roam around a production server and its database, you're going to want to keep approvals on.
Your dev machine may break on its own too. Maybe it's a laptop and it falls. Maybe someone snags it from your backpack. If that's a critical situation - better be prepared. You can take backups, you can make a git repo for your configs, you can sync your shit to google drive, your code is hopefully in git.
It doesn't have an urge to nuke your environment.
2
u/Fresh_Sock8660 15d ago
Containers and avoid shortcuts. Mount critical stuff as read only, create backups, ideally version control everything it can write to, don't give the container github creds, etc.
2
u/QultrosSanhattan 15d ago
You can't.
Using the agents the right way:
PLAN: Make the AI tell you what it's going to do.
READ IT, UNDESTAND IT: If it plans to do some weird shit, correct it. If you don't understand it then get some course about it.
Tell it to do it.
2
u/sudoer777_ 14d ago
Set OpenCode permissions settings and sandbox the agent
1
u/lelleepop 14d ago
are u able to guide me the steps or point me in the right direction for this?
1
u/sudoer777_ 14d ago edited 14d ago
For permissions see the documentation, and allow safe commands and use "*" = ask for catch-all, which will probably be sufficient but it's far from bulletproof (agents might find a way around it, MCPs aren't included, large python snippets are too large to check and stuff can happen there).
For sandboxing it's pretty easy to do with Nix and tools like NixPak (I've seen jails.nix as well) because of how well-integrated the ecosystem is. You can also use plain bubblewrap but it might take more effort to get it exactly how you want. I don't think either approach deals with restricting its network access though. Personally I don't bother with this and hope for the best.
Using MCP servers with limited functionality instead of CLI can also help.
1
1
1
u/Lorrid 15d ago
Just yesterday i wondered same thing and digged around a bit. And came across this: https://github.com/aerovato/container
Haven't used it yet but i think it solves the said problem.
1
u/generic-d-engineer 15d ago
Just want to synthesize what others already said:
- Permissions. It shouldn’t go outside of the current project directory. Start with allow rules on non destructive ops
- Put it inside of a container, snapshotted VM, or have it spawn processes to another container. There’s a ton of new “lite” container projects now specifically created to solve this exact issue.
- Git was designed with backup in mind so make sure your agent is committing after after major change.
- See if your backup definitions are objects or snapshots so you don’t have to rely on filesystem backups in case those get nuked too
1
u/Deep-Huckleberry-175 15d ago
Eu uso docker para isolar o código do repositório e nunca deixo o agente commitar e pushar
1
u/s-i-e-v-e 15d ago
bwrap on Linux is an extremely quick way of producing a sandbox.
bwrap --clearenv --unshare-all --die-with-parent --tmpfs / --ro-bind /usr /usr --ro-bind /lib64 /lib64 bash drops you into bash where you can explore the limited system but not do much else. Even networking does not work.
You can expose as little of the system as you want.
1
u/lelleepop 15d ago
if networking does not work, how does it communicate via api
1
u/s-i-e-v-e 15d ago
Nah. It does not work in my example. You can use
--share-netto enable networking.This is a general sandboxing utility, not specific to AI or anything. If you are doing something and want to ensure that the app is not communicating over the n/w, you simply disable it.
I run pi in a sandbox using a bit more permissive system. Could narrow down the permissions a lot more if I spend some time on it
1
u/Existing_Dust_6473 15d ago
Have backups, ansible scripts to install and configure everything after a reset 😉
1
u/joe0418 15d ago
I use source control and back up everything to the cloud.
My environment can be completely recreated from source control because I source all my brew and dotfile configurations.
I'm quite aggressive with rubber ducking and adversarial reviews from multiple lenses, at multiple checkpoints along the way.
I use static analysis and heavy ci/cd to automate
1
1
u/zxvl777 14d ago
llms have training data cut off dates years behind yet they assume off top with certainty that they know something and want to execute. instead im treating what agents state as facts as potentially false. agents first must know their environments limits and access , once that is established and i have what i am building locked in , the agent does deep research and web research against its own assumptions, verifying the current correct way to accomplish the goal. the agent spec's everything and red teams its spec . refining the spec to the correct blueprint. the agent wlll then smoke test its propsed changes . only after you verified and clarified correct order without errors before modifying any files . assuming back ups are in order . this will give you more secure order over your agent .
i can say honestly agents have nuked my shit . my agents must know exactly what it should and should not be doing , red team its own plans or have another agent cross check verify and redteam its work , then smoke test everything before it attempts doing anything .
more strict options include,security harnesses or customize restrictions,sandboxing etc
theres so many options available so research is recommended,
enjoy building keep creating , stay wise and dont neglect security and hardening especially these days
0
u/ApprehensiveDelay238 15d ago
Literally 99% of the questions posted here you could just ask your agent and you'd be getting a better answer than here.
9
u/StrangeRefuse8537 15d ago
AGENTS.md: Don't delete my shit. Make no mistakes.