Primary question: Are you prepared to run an unsandboxed AI agent with shell execution on your local machine?
RepoDaily adoption score
RepoDaily rates this as 87/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.
5 source(s) across 3 source category/categories, plus a RepoDaily-specific evidence module when available.
5 workflow step(s), 6 next-action step(s), and 6 command/install signal(s) were detected.
Trending momentum is +417 stars, with maintenance/release/issue signals counted when present.
Risk is marked high, with 7 security note(s) and 4 explicit skip condition(s).
3 opportunity lens item(s), 4 alternative(s), and 4 type-specific section(s) support differentiation.
License source or license wording is present.
7 AI/agent-related signal(s) were detected in the article text and metadata.
Project overview
OpenCode is a TypeScript-based open-source AI coding agent maintained by anomalyco. It runs locally, presenting a terminal UI built with SolidJS and opentui, a desktop app wrapping Electron, and a headless API server on port 4096. The agent is granted direct access to shell execution, file operations, and web requests — the three primitives that make it useful, and the three that make its security posture critical.
Unlike many tools that quietly understate their blast radius, OpenCode's SECURITY.md is unusually direct: the permission system is explicitly described as a UX feature, not a security boundary. There is no sandbox. If a user needs true isolation, the maintainers recommend running OpenCode inside a Docker container or VM. This honesty is refreshing for a security analysis — the project tells you exactly what it does and does not protect against.
The project ships under the MIT License, distributes via npm as opencode-ai, and supports a wide range of install paths: Homebrew, Scoop, Chocolatey, pacman, AUR, mise, Nix, and a curl installer. A desktop app is in beta for macOS, Windows, and Linux. The codebase is a Bun-powered monorepo with packages for the core server, TUI, shared web components, desktop shell, and plugin SDK.
Why it is trending now
- 417 stars in the trending period, ranked #12, driven by multi-platform installer coverage and an expanding provider ecosystem
- Beta desktop app for macOS (Apple Silicon and Intel), Windows, and Linux via .dmg, .exe, .deb, .rpm, and .AppImage
- Headless API server on port 4096 enables CI/CD and programmatic integration, not just interactive TUI usage
- New providers are added through a separate models.dev repository, keeping the core agent decoupled from model-specific code
- 21 community-translated README files spanning English, Chinese, Japanese, Korean, Arabic, and 16 other languages
Problem it solves
- Running an LLM-driven agent with shell access locally means a prompt injection or hallucinated command can delete files, exfiltrate secrets, or install malware
- Server mode, when enabled without OPENCODE_SERVER_PASSWORD, runs unauthenticated on the local network — anyone who can reach the port has full agent access
- MCP servers configured by the user fall outside OpenCode's trust boundary, creating a transitive supply-chain risk
- Malicious config files are classified as out-of-scope because users control their own config, but shared or cloned configs carry real danger
- Data sent to LLM providers is governed by provider policies, not OpenCode — code, secrets, and context leave the machine
How it works
- Install via a package manager (npm i -g opencode-ai, brew install anomalyco/tap/opencode, scoop install opencode) or the curl installer at opencode.ai/install
- Launch the TUI by running opencode in a project directory, or start the headless server with opencode serve on port 4096
- Configure an LLM provider through the models.dev integration — the agent sends your code context and prompts to the configured provider
- The agent requests permission before executing shell commands, writing files, or accessing the web — but this is a UX confirmation, not a sandbox barrier
- For network-accessible deployments, set OPENCODE_SERVER_PASSWORD to enforce HTTP Basic Auth on the server endpoint
Product demo and interface preview
Integration Surface: Server Mode, MCP, and Provider Boundary
OpenCode exposes three integration surfaces that determine its security envelope. The headless API server (opencode serve) listens on port 4096 by default and can be changed with --port. When server mode is enabled, SECURITY.md states that without OPENCODE_SERVER_PASSWORD the server runs unauthenticated with a warning. The responsibility for securing that endpoint falls entirely on the end user — the project classifies server access when opted-in as expected behavior, not a vulnerability.
MCP (Model Context Protocol) servers are the second surface. Any external MCP server a user configures is explicitly outside OpenCode's trust boundary. This means a compromised or malicious MCP server can instruct the agent to execute arbitrary shell commands, and OpenCode will treat that instruction the same as one from the user.
The third surface is the LLM provider. All code context, prompts, and potentially secrets are sent to the configured provider's API. SECURITY.md states this data handling is governed by provider policies, not by OpenCode itself.
Command Surface: CLI Entry Points and Server Controls
- opencode or opencode <directory> — launches the TUI in interactive mode
- opencode serve — starts the headless API server on port 4096 (override with --port)
- opencode web — starts the server and opens the web interface in a browser
- bun dev serve — development equivalent, also defaults to port 4096
- OPENCODE_INSTALL_DIR, XDG_BIN_DIR, $HOME/bin, $HOME/.opencode/bin — priority order for the curl installer's binary path
- OPENCODE_SERVER_PASSWORD — sets HTTP Basic Auth credentials for server mode (opt-in, but required for any network-exposed deployment)
Try-It Path: From Install to First Agent Run
The fastest path is npm i -g opencode-ai@latest, followed by running opencode inside a project directory. The TUI renders via opentui (a SolidJS terminal renderer at version 0.4.3 in the catalog). The README warns to remove versions older than 0.1.x before installing, suggesting breaking changes in the early release cycle.
For isolated evaluation, the recommended approach is to run OpenCode inside a Docker container or VM — the maintainers explicitly state this in SECURITY.md. Developers evaluating the project should clone a throwaway repository, containerize the environment, and observe which permission prompts appear during a typical coding task.
The desktop app beta is installable via brew install --cask opencode-desktop on macOS or scoop install extras/opencode-desktop on Windows, providing a non-terminal alternative for users who prefer a GUI.
Adoption Checklist: Security Questions to Answer Before Production Use
- Will server mode be enabled? If yes, is OPENCODE_SERVER_PASSWORD set and is the port firewalled?
- Which MCP servers will be configured? Have their source repositories and maintainers been reviewed?
- Which LLM provider receives your code context? Does that provider's data policy permit retention or training?
- Will OpenCode run in a container/VM, or with full local user privileges?
- Are there shared opencode config files in the repository? Who controls their contents?
- Is the Bun 1.3+ runtime available in the deployment environment (required for development builds)?
Who should pay attention?
Good fit if
- Individual developers who want a local AI agent and understand the non-sandbox model
- Teams that can containerize OpenCode in Docker or VMs before granting codebase access
- CI/CD pipelines that need headless code generation via the port 4096 API server with authentication
- Contributors adding LSP, formatter, or provider support — CONTRIBUTING.md lists these as commonly merged
Skip for now if
- Environments where an unsandboxed agent with shell access is unacceptable
- Shared or multi-tenant machines where server mode cannot be password-protected and firewalled
- Projects with strict data residency requirements that prohibit sending code to external LLM providers
- Teams that cannot review or trust MCP server dependencies in their supply chain
Risks and cautions
OpenCode grants an LLM-driven agent shell execution, file writes, and web access without sandbox isolation. The permission system is a UX confirmation prompt, not a security barrier. Server mode can expose an unauthenticated API endpoint if OPENCODE_SERVER_PASSWORD is not set.
- SECURITY.md explicitly states: 'OpenCode does not sandbox the agent'
- Shell execution, file operations, and web access are core agent capabilities, not optional plugins
- Server mode runs unauthenticated by default when enabled without a password
- MCP servers configured by users fall outside the project's trust boundary
- The project does not accept AI-generated security reports, limiting community-driven vulnerability discovery
- No sandbox: the permission system prompts for confirmation before actions but provides no isolation — documented in SECURITY.md
- Server mode is opt-in only; without OPENCODE_SERVER_PASSWORD it runs unauthenticated with a warning
- Sandbox escapes are classified as out-of-scope because the permission system is not designed as a sandbox
- Malicious config files are out-of-scope because users control their own configuration
- LLM provider data handling is governed by provider policies, not by OpenCode
- Vulnerability reports must go through GitHub Security Advisory; AI-generated reports result in automatic project bans
- Escalation path: email security@anoma.ly if no acknowledgement within 6 business days
Alternatives to compare
| Approach | When to use | Trade-off |
|---|---|---|
Continue | You want an IDE-integrated AI coding assistant with a more constrained permission model | Free / open source |
Aider | You want a terminal-based AI pair programmer focused on git-tracked edits | Free / open source |
Cursor | You want a commercial IDE with built-in AI and managed infrastructure | Subscription |
GitHub Copilot CLI | You want shell suggestions without granting autonomous execution to an agent | Subscription |
What this trend reveals
Container-First Deployment Packaging
SECURITY.md recommends Docker or VM isolation, but the project does not ship an official container image. A hardened Dockerfile with non-root user, read-only filesystem, and network policies would address the primary adoption blocker for security-conscious teams.
Check whether the opencode releases page or packages/ directory already contains a Dockerfile; if not, this is an unmet need.
MCP Server Audit Tooling
MCP servers fall outside OpenCode's trust boundary, yet no tooling exists to audit or sandbox them. A pre-flight checker that scans configured MCP servers for known-bad patterns or excessive permissions would reduce transitive supply-chain risk.
Search the issue tracker for 'MCP' and 'audit' to confirm no existing initiative addresses this gap.
Server Mode Hardening Guide
The OPENCODE_SERVER_PASSWORD mechanism uses HTTP Basic Auth, which has known weaknesses. A documented guide covering reverse proxy setup, TLS termination, and IP allowlisting would help teams deploy the headless server safely.
Review the docs site at opencode.ai for existing server-mode deployment guidance.
RepoDaily verdict
OpenCode is a capable, well-engineered local AI coding agent with an unusually honest security posture. Its explicit non-sandbox documentation is both its greatest strength (transparency) and its greatest risk (no isolation by design). Teams that containerize it and lock down server mode will get a powerful agent; teams that run it with full local privileges on sensitive machines are accepting significant blast radius.