OpenCode can be safe to use if you treat it like any other tool that can read your code and run actions on your machine: safety depends on your configuration, what tools you allow it to run, and whether you share sessions publicly. The core project is open source and runs locally (terminal, desktop sidecar server, IDE extension), which gives you visibility into what it’s doing and where data is stored. But “safe” does not mean “risk-free”: OpenCode can access your repository files, can run shell commands via its bash tool, and can upload conversation history if you enable sharing. The right mental model is: OpenCode is a local automation client that can call remote AI providers; you should lock down permissions, keep secrets out of prompts, and disable features you don’t need.
Practically, the biggest safety levers are permissions, tools, and sharing. OpenCode includes a permissions system that lets you set each tool to allow, ask, or deny, so you can require explicit approval for anything that can change state (file edits, patches, shell commands). If you want a safer default, configure edit and bash to ask so nothing writes files or executes commands without you approving it first; this is especially important in large repos where a careless “apply patch everywhere” can do real damage. You should also evaluate what plugins, custom tools, or MCP servers you’ve enabled, because those extensions can add new capabilities that may touch network services, files, or credentials. Finally, treat session sharing as a data-exfiltration switch: when you share a conversation, OpenCode creates a public URL and syncs the conversation history to hosting infrastructure so others can view it. If you work with private code, customer data, or anything regulated, keep sharing in manual mode (the default) or set it to disabled, and do not paste secrets (tokens, private keys, database passwords) into prompts.
A safe workflow is mostly boring—and that’s good. Keep your provider API keys in OpenCode’s local credential store (it saves them in a local auth.json file) rather than sprinkling them into shell history or repo configs, and restrict filesystem scope by running OpenCode only inside the project directory you intend to work on. If you’re doing sensitive development—say you’re integrating a vector database such as Milvus or Zilliz Cloud—be extra careful about logs and prompts: don’t paste production queries containing user identifiers, don’t paste connection strings, and consider using least-privilege database users for dev/test environments. For high assurance, run OpenCode in a sandboxed environment (a dedicated dev container or VM), keep bash permissioned to ask, and disable automatic sharing. With those guardrails, OpenCode becomes “safe enough” for many engineering teams, because you retain control over what actions run and what data leaves your machine.