Repository navigation
OpenCode should have better/safer defaults to be more security minded #5076
Description
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 defaultpermission.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”.
Activity
github-actions commentedon Dec 4, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
thdxr commentedon Dec 4, 2025
hey thanks for writing this up - we are looking at all the things you mentioned
we're currently redesigning how permissions work so after that we're going to re-evaluate what our defaults look like
for update we're going to have a prompt in app that you can say yes to when you want to update
and a few other things i'm thinking about
appreciate you bringing these up politely, we usually get messages assuming we're idiots or weird threats
calper-ql commentedon Dec 4, 2025
Thanks for your work as well. This is an amazing tool and I really enjoy using it.
Looking forward to how it will grow.
[-]Opencode is a giant security risk: Malware like behavior[/-][+]OpenCode should have better/safer defaults to be more security minded[/+]rekram1-node commentedon Dec 4, 2025
I updated the title a bit so we can track this better, if you feel like it isn't accurate feel free to reword it
calper-ql commentedon Dec 4, 2025
I like it. Original sounded a bit too urgent as I thought it should be but given that the team is actively re-considering the issue the current title is fair.
abumalick commentedon Jan 4, 2026
A note on granular bash command permissions
The best experience I've found for managing bash command permissions is in the Kilocode VS Code extension. When the LLM wants to execute a command, it prompts for approval and lets you choose the level of auto-approval that fits your workflow.
For example, if the LLM runs:
You can choose to always approve at any granularity level:
bun— approve all bun commandsbun run— approve all bun run commandsbun run test— approve all test runsThis approach strikes an excellent balance: it enforces meaningful permissions while letting users dial in exactly how much autonomy to grant, keeping productivity high without sacrificing control.
docs: assessment of next 4 upstream issues (anomalyco#2755, anomalyco…
jstasiak commentedon Mar 13, 2026
Still an issue, I was really surprised to see opencode just start running commands without confirmation.
johnnykang commentedon Mar 26, 2026
just a update check.
is this concern on the road map? OpenCode is very useful and my employer is not comfortable to approve me using the tool due to these concerns. it sounds too risky if something went south.
Michael-Z-Freeman commentedon Mar 27, 2026
Whatever the devs decide is great. But there needs to be a warning on first run.
mikolaj-wroblewski commentedon Apr 14, 2026
I want to add something on top of it, I am in favor of configuring safe operations like
read/grep/exploreout of the box with allow or at least asking the user when first time launching or even creating a new session if one wants to allow read operations out of the box (read file / read directory, etc.)While having more secure defaults is great, I also want to emphasize user experience. I know I can configure reads in the configuration with allow, but what if I want to have more controlled session from time to time?
divinedev7777 commentedon Apr 14, 2026
I fully support this, also I agree completely with @mikolaj-wroblewski take.
github-actions commentedon Jun 14, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
ony commentedon Jul 12, 2026
That's so cool for this issue to be auto-closed as not planned by github-actions !