Permissions & isolation

You’ve been letting OpenCode run with whatever defaults it shipped, and so far that’s been fine — feedmill is a Go CLI and a sync server you inherited, and most of your work has been reading parsers and asking questions. But the jobs ahead don’t all carry the same risk. Touching internal/store, where the deduped reading queue lives, is editing the one thing in this project you can’t trivially regenerate — the parsed history of dozens of feeds you’ve been pulling for weeks. Hacking on a throwaway script to probe one flaky Atom source is the opposite: nothing it can break is worth protecting. Handing both of those the same amount of trust is wrong in both directions — too loose on the store, too fussy on the scratch script. This chapter is about making the leash fit the job.

The good news is that OpenCode’s permission model is built for exactly this. Control is per-tool per-agent: each agent carries its own map of what edit, bash, read, and the rest are allowed to do — allow, ask, or deny — and you can go finer than a whole tool, gating bash down to specific command patterns. So “let it read anything but ask before every edit, and never let it run git push” isn’t a vibe you maintain by hand; it’s a policy you write down once. The catch you’ll meet at the end is just as important: as of writing, OpenCode ships no built-in OS sandbox , so when you genuinely need to contain what the agent can reach on your machine, the answer isn’t a config flag — it’s running the whole CLI inside a container.

We’ll build that up in three moves:

• Set permissions per tool, per agent — write the policy map that makes edit ask and bash ask while reads run free, then tighten bash to the exact commands you trust around your feed store — Set permissions per tool, per agent
• Switch agents to switch policy — because the permission map rides on the agent, picking an agent is picking a posture; build an audit primary that can read everything and write nothing, OpenCode’s answer to the named-profile idea other tools bolt on separately — Switch agents to switch policy
• Isolate by running in a container — face the sharp edge honestly: permissions gate OpenCode’s tools, not your OS, so for real isolation you put the CLI in a container — which is exactly where OpenCode being just-a-CLI pays off — Isolate by running in a container

Do these as one continuous stretch on feedmill and a single idea threads through all three: the unit of trust in OpenCode is the agent. Permissions are properties of an agent, switching agents switches the entire policy, and the one thing permissions can’t do — wall the agent off from your machine — is handled one layer out, by changing where the agent runs rather than what it’s allowed to call. Get that mental model now and the container you stand up in the last lesson stops being a detour: it’s the same agent you’ve been driving all chapter, dropped into a box that finally makes “loose” safe. That’s also the box CI will reach for two chapters on, when nobody’s sitting at the keyboard to answer an ask.