Blog
OpenCode --auto: what auto mode approves, and the deny rules it never touches
OpenCode's version of yolo is narrower than most, on purpose. It only answers the questions that were going to be asked, and the answer is only yes where nobody said no.
OpenCode's --auto, also usable as opencode run --auto, approves every permission request that would otherwise ask, and explicit deny rules still block. Out of the box that includes a deny on reading .env files. What OpenCode does not have is a sandbox of its own, so in auto mode the deny list is the only thing standing between a command and your machine. Write a short one, and keep keys out of reach altogether: Forkbench's Vault uses a key without OpenCode ever holding it.
Three answers, and auto only changes one
Every OpenCode permission rule resolves to allow, ask or deny, set per tool in opencode.json and matched with wildcards. A rule like "git *": "allow" runs every git command without a prompt, and "rm *": "deny" refuses every rm.
--auto turns every ask into an allow. OpenCode's documentation is precise about the boundary: auto mode only changes requests that would otherwise ask for approval, and explicit deny rules are still enforced.
So the config equivalent of --auto, "permission": { "*": "allow" }, is wider than the flag. The flag keeps your denies. A blanket allow written into the config is easy to read as the same thing, and it is not.
The default that is already doing work
OpenCode ships one deny you may not have noticed. Reading is allowed in general, but .env files are denied by default, with .env.example carved back out.
That is a good default, and it is worth knowing its edges. It covers OpenCode's read tool. A shell command that cats the file, a test runner that loads it, or a key that was exported into your shell before OpenCode started are all outside that rule.
The plan and build agents are a separate axis again. Plan cannot edit, build can, and --auto decides how often either one stops to ask, not what it is able to do.
No sandbox to fall back on
OpenCode does not ship an operating-system sandbox. Commands run in your shell, as you, with your network. Third-party wrappers exist, but none of them come with the binary.
That makes --auto in OpenCode a cleaner trade than in tools where the flag also removes a sandbox: you lose the human and nothing else. It also means the deny list is the whole of your protection, so it is worth five minutes. Deny the commands you cannot undo, deny writes to anything that holds a secret, and put the session on its own git worktree.
How this works in Forkbench
Forkbench is a desktop app for running coding agents, and OpenCode runs in it as the opencode command you installed, with your opencode.json untouched. It reaches the Thread's notes, board and keys through the fb command on its PATH.
It adds the two things OpenCode leaves to you. A Thread can be locked to a set of folders by the kernel, inherited by every process OpenCode starts, which is the sandbox the binary does not have. And a key in Vault is used by the command that needs it without the value entering OpenCode's environment, which closes the edges of the .env rule above: there is no file and no variable for a shell command to find.
The limit: a folder lock bounds files, not the network, and a command you let run can still print what it was handed.
Related: Yolo mode in every coding agent, compared, OpenCode in Forkbench, Claude Code: what --dangerously-skip-permissions actually skips
Frequently asked
Does OpenCode have a yolo mode?
Its equivalent is --auto, for both the TUI and opencode run. It approves every request that would otherwise ask, while explicit deny rules keep blocking. The TUI also has an auto mode toggle.
Does OpenCode --auto override deny rules?
No. OpenCode's documentation states that explicit deny rules are still enforced in auto mode, which only changes requests that would have asked for approval.
Can OpenCode read my .env file?
Its read tool cannot by default, because OpenCode ships a deny rule for .env files. A shell command can still read one, and a key already exported into your environment is outside that rule entirely, so keep secrets out of both (see stopping an agent reading your .env file).
Does OpenCode run commands in a sandbox?
No. OpenCode has no built-in operating-system sandbox, so commands run in your shell with your permissions and network, whether or not you use --auto. Bounding it means adding a boundary from outside, such as a folder lock or a container.