We do not accept AI generated security reports. We receive a large number of these and we absolutely do not have the resources to review them all. If you submit one that will be an automatic ban from the project.
OpenCode is an AI-powered coding assistant that runs locally on your machine. It provides an agent system with access to powerful tools including shell execution, file operations, and web access.
OpenCode does not sandbox the agent. The permission system exists as a UX feature to help users stay aware of what actions the agent is taking - it prompts for confirmation before executing commands, writing files, etc. However, it is not designed to provide security isolation.
If you need true isolation, run OpenCode inside a Docker container or VM.
Server mode is opt-in only. Loopback binds (localhost, 127.0.0.1, and ::1) may run unauthenticated for local development. Set OPENCODE_SERVER_PASSWORD to require HTTP Basic Auth.
Non-loopback binds, including 0.0.0.0 and mDNS defaults, refuse to start without OPENCODE_SERVER_PASSWORD. Users can override this by passing --allow-insecure-no-auth or setting server.allowInsecureNoAuth.
If a user opts into unauthenticated network access with --allow-insecure-no-auth or server.allowInsecureNoAuth, they are responsible for securing the server. Any functionality exposed by that server is expected behavior, not a vulnerability.
| Category | Rationale |
|---|---|
| Server access when opted-in | If you enable server mode, API access is expected behavior |
| Sandbox escapes | The permission system is not a sandbox (see above) |
| LLM provider data handling | Data sent to your configured LLM provider is governed by their policies |
| MCP server behavior | External MCP servers you configure are outside our trust boundary |
| Malicious config files | Users control their own config; modifying it is not an attack vector |
We appreciate your efforts to responsibly disclose your findings, and will make every effort to acknowledge your contributions.
To report a security issue, please use the GitHub Security Advisory "Report a Vulnerability" tab.
The team will send a response indicating the next steps in handling your report. After the initial reply to your report, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.
If you do not receive an acknowledgement of your report within 6 business days, you may send an email to [email protected]