I like OpenCode (https://opencode.ai/). It's a serious open-source coding agent, the kind of thing I'd actually run on my own box instead of renting someone else's. But here's the thing nobody says out loud: open-source means you can read the code. It does not mean the code is safe to run.
I've been burned by this assumption before, and I've watched other people get burned worse. The logic goes "it's open source, so the community would have caught anything bad." That's true for supply-chain attacks and backdoors — mostly. It's not true for the boring, everyday ways an agent can wreck your week. An agent doesn't need to be malicious to cost you money or delete your work. It just needs to be confident.
So before you adopt OpenCode — or any open-source agent — run it through the same three guardrail checks you'd demand from a closed-source tool. Because the license being permissive doesn't make the agent careful.
1. Approval gates. Does it actually stop?
The first question I ask about any agent: when it wants to do something destructive, does it have to ask? And I don't mean "does it have a setting for that." I mean, does the tool enforce it, or does it just suggest it?
A lot of agents have an approval mode that's really a suggestion mode. The model generates a command, the UI shows it to you, and if you don't click fast enough, it just... proceeds. Or worse, the approval is per-session, so you approve once and it runs wild for the next hour. That's not a gate, that's a speed bump.
Check how OpenCode handles this. Can you require approval per-command? Can you scope it — approve file edits but force a prompt on anything that touches git history, environment variables, or network calls? If the answer is "you can just watch the log," that's not a guardrail, that's a dashboard.
2. Budget limits. Can it spend your money?
Coding agents are expensive in two ways. First, the obvious one: API costs. An agent that loops on a failing test can burn through tokens like a teenager with a credit card. I've seen a single stuck refactor cost more than a month of my own usage. If the tool doesn't let you set a hard cap — not a soft warning, a hard stop — then it's not production-ready, it's a demo.
Second, the less obvious one: compute. If the agent can spawn builds, run tests, or spin up containers, it can eat your CPU and your cloud bill. Open-source agents often default to "run anything the model wants," because that's what makes them impressive in demos. Impressive demos are how you get a surprise invoice.
Check whether OpenCode has a budget mechanism. If it doesn't, you need to wrap it yourself — a timeout, a token cap, a container with limits. And if you can't wrap it, that's a real answer too. It just means the tool isn't ready for your workflow yet.
3. Sandboxing. What can it actually touch?
This is the one people skip, and it's the one that hurts. An agent that can read your whole filesystem, access your SSH keys, and run arbitrary shell commands is not a tool, it's a liability with a nice UI.
The question isn't "is the code trustworthy." The question is "what happens when the model makes a mistake." Because it will. Not because it's evil — because it's a language model. It will misread a path, guess a flag, or "helpfully" clean up a directory that wasn't the one you meant.
So check: does OpenCode run in a sandbox by default? Can you restrict it to a working directory? Can you block it from reading your ~/.ssh, your .env files, your package manager credentials? If the answer is "it runs as your user, so it can do anything you can do," then you need to run it in a container or a VM yourself. That's not optional, that's the minimum.
The uncomfortable part
Here's where I hedge, because I haven't fully tested OpenCode's guardrails myself. I've read the docs, I've poked at the repo, and it looks like a real project with real intent. But "looks like" is not "verified." The honest position is: I want to like it, and I'm going to test it properly before I let it near anything I care about.
And that's the actual tip. Not "use OpenCode" or "don't use OpenCode." The tip is: treat open-source agents with the same suspicion you'd treat a closed-source one. Read the code if you can, but more importantly, test the behavior. Give it a throwaway repo, a fake credential, a directory you don't care about, and see what it does when things go wrong. That's the only benchmark that matters.
Open-source gives you the freedom to check. It doesn't give you the safety. Those are different things, and conflating them is how you end up with a deleted branch and a story for the postmortem.
I'll be running OpenCode through these checks this week. If it passes, I'll tell you. If it doesn't, I'll tell you that too. That's the deal.
Top comments (0)