OpenCode should have better/safer defaults to be more security minded
First: OpenCode is an awesome project.
However, in its current default configuration it behaves like a high-privilege remote control agent and poses a serious security risk.
Current behavior
On a standard, recommended install:
-
Allow-by-default permissions
OpenCode can freely read/write project files and run shell commands with no strong, unavoidable first-run warning. -
Auto-update enabled by default
The tool silently updates itself on startup unless the user discovers and disablesautoupdate. Code with file + shell access is replaced without explicit approval of each new version. -
Bash access from any model
Any configured remote or local model can trigger shell commands with the same privileges as the user.
Combined, this is logically equivalent to installing an auto-updating remote access tool on a developer machine: if the update pipeline, binary distribution, or a model provider is compromised, an attacker gets a powerful foothold on every machine running OpenCode with defaults.
I am not saying OpenCode is malware or accusing the team of malicious intent. I am saying the current defaults create malware-class risk for users, especially given how widely the tool is now used.
On “we’ve thought about this a lot”
If the answer is “we discussed it and decided UX is better without prompts because most people turn them off”, I think that is not a sufficient bar for a tool this powerful.
In my view, once a project reaches this level of adoption and capability, there is an ethical responsibility to:
- Treat safety as the default and “do anything automatically” as explicit opt-in.
- Make the risks obvious to non-expert users, not hidden in config.
Having an MIT license or a power-user audience does not remove that responsibility.
Requested changes
-
Secure defaults
-
permission.edit = "ask"by default -
permission.bash = "ask"(or"deny") by default
-
-
Auto-update as explicit opt-in
- Default
autoupdatetofalseor “notify only”.
- Default
-
First-run security screen
- Explain file access, shell execution, remote model control, and update behavior.
- Let users explicitly choose between:
- “Safe / ask before actions” (default)
- “Permissive / allow edits and commands”.