anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

OpenCode should have better/safer defaults to be more security minded #3309

New Issue
Open
opened 2026-02-16 17:39:36 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 17:39:36 -05:00
Owner
Copy Link
Copy Source

Originally created by @calper-ql on GitHub (Dec 4, 2025).

Originally assigned to: @thdxr on GitHub.

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:

  1. Allow-by-default permissions
    OpenCode can freely read/write project files and run shell commands with no strong, unavoidable first-run warning.

  2. Auto-update enabled by default
    The tool silently updates itself on startup unless the user discovers and disables autoupdate. Code with file + shell access is replaced without explicit approval of each new version.

  3. 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

  1. Secure defaults

    • permission.edit = "ask" by default
    • permission.bash = "ask" (or "deny") by default

  2. Auto-update as explicit opt-in

    • Default autoupdate to false or “notify only”.

  3. 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”.
Originally created by @calper-ql on GitHub (Dec 4, 2025). Originally assigned to: @thdxr on GitHub. 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: 1. **Allow-by-default permissions** OpenCode can freely read/write project files and run shell commands with no strong, unavoidable first-run warning. 2. **Auto-update enabled by default** The tool silently updates itself on startup unless the user discovers and disables `autoupdate`. Code with file + shell access is replaced without explicit approval of each new version. 3. **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 1. **Secure defaults** - `permission.edit = "ask"` by default - `permission.bash = "ask"` (or `"deny"`) by default 2. **Auto-update as explicit opt-in** - Default `autoupdate` to `false` or “notify only”. 3. **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”.
yindo commented 2026-02-16 17:39:36 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 4, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #4667: Limiting access for tools in a safer way
  • #4783: Please, change autoupdate to notify by default
  • #1961: Unifying tools and permissions
  • #3824: How does opencode handle security checks?

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Dec 4, 2025): This issue might be a duplicate of existing issues. Please check: - #4667: Limiting access for tools in a safer way - #4783: Please, change autoupdate to notify by default - #1961: Unifying tools and permissions - #3824: How does opencode handle security checks? Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:39:37 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (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

@thdxr commented on GitHub (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
yindo commented 2026-02-16 17:39:37 -05:00
Author
Owner
Copy Link
Copy Source

@calper-ql commented on GitHub (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.

@calper-ql commented on GitHub (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.
yindo commented 2026-02-16 17:39:37 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (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

@rekram1-node commented on GitHub (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
yindo commented 2026-02-16 17:39:37 -05:00
Author
Owner
Copy Link
Copy Source

@calper-ql commented on GitHub (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

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.

@calper-ql commented on GitHub (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 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.
yindo commented 2026-02-16 17:39:37 -05:00
Author
Owner
Copy Link
Copy Source

@abumalick commented on GitHub (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:

bun run test -- --files=tests/browser/scenarios/errors.spec.ts --tests="Invalid checkout URL shows error"

You can choose to always approve at any granularity level:

  • bun — approve all bun commands
  • bun run — approve all bun run commands
  • bun run test — approve all test runs
  • The full command — approve only this exact invocation

This 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.

Image
@abumalick commented on GitHub (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: ``` bun run test -- --files=tests/browser/scenarios/errors.spec.ts --tests="Invalid checkout URL shows error" ``` You can choose to always approve at any granularity level: - `bun` — approve all bun commands - `bun run` — approve all bun run commands - `bun run test` — approve all test runs - The full command — approve only this exact invocation This 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. <img width="947" height="403" alt="Image" src="https://github.com/user-attachments/assets/5b81ed04-9773-482f-8b39-6452e68d9184" />
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3309
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?