OpenCode

OpenCode runs entirely with the developer's own operating-system authority and does nothing to narrow it. Every shell command and every locally launched MCP server receives the full parent environment, so API keys, cloud credentials, SSH agent sockets and gh/git auth are all reachable. There is no per-tool identity or credential scoping, and the permission rules decide which tools run, not which credentials they get. A hijacked session can therefore act as the user across every service the machine is logged into.

OpenCode has a real permission engine: it can ask before each shell command (parsed per sub-command with tree-sitter) and shows file diffs before edits, with once/always/reject answers. But the default build agent's ruleset is "allow everything", so in a fresh install shell commands, file writes, web fetches and MCP tool calls run without any human approval; only reads outside the project, .env reads and repeated identical calls prompt. The README and SECURITY.md describe the permission system as prompting before commands, which the shipped defaults do not do; enforcement in another mode also does not cover every path. Git-based snapshots let file changes be reverted, but pushes, deletions outside the project and network calls cannot be undone.

The default tool set includes an unrestricted shell, file write/edit/patch, and a web fetcher that accepts any http(s) URL. File tools and the shell's file commands check whether a path lies inside the project, but the check is not a strict boundary and only triggers a prompt rather than a refusal. The fetcher has no host allowlist and no block on internal or metadata addresses. Tools can be disabled individually by setting deny rules, but everything is on by default.

There is no isolation of any kind: shell commands, MCP stdio servers, custom tools and plugins run as ordinary processes (or in-process code) under the user's account with the full environment. The project's own security policy says plainly that it does not sandbox the agent and that the permission system is not a security boundary. Combined with the default allow-all rules, any command the model chooses runs on the host immediately.

Web pages, files in the repository, MCP tool results and MCP server instructions all enter the model's context with no marking or separation, and MCP servers' instructions are appended to the system prompt. Because the default rules allow shell and web fetch without approval, a successful prompt injection can read secrets and send them out (curl, webfetch to any URL) and also take irreversible actions such as pushing code or deleting files, with no human in the loop.

Opening OpenCode inside a repository silently loads that repository's configuration: opencode.json, the .opencode directory's agents, commands and config, plugins in .opencode/plugin(s), and custom tools in .opencode/tool(s), which are imported and executed in-process at startup. Project config can also declare MCP servers (launched automatically), npm plugins, permission rules, provider endpoints and automatic session sharing. AGENTS.md/CLAUDE.md instruction files are also loaded silently. There is no workspace-trust prompt; the only off switch is an environment variable. Because edits are allowed by default, a hijacked session can also write these files and plant a backdoor that fires in every later session and for anyone who clones the repo.

Extensions load with no verification and no consent. Plugin files in .opencode/plugin(s), custom tools in .opencode/tool(s), and npm plugins named in any config (including a repository's own opencode.json) are imported straight into the OpenCode process; npm plugins named without a version resolve to latest each time. MCP servers declared in config start automatically as child processes with the full environment. The one mitigation found is that npm install runs with lifecycle scripts disabled.

Provider credentials are stored in a plaintext auth.json with owner-only permissions, and the read tool asks before opening .env files. Beyond that there is no redaction: shell commands and MCP servers receive the whole environment, tool output goes to the model unfiltered, and the shell can read .env files without prompting. Telemetry is off unless an OpenTelemetry endpoint is configured, but a repository's own config can switch on automatic session sharing, which uploads transcripts to the share service.

Every session is stored in a SQLite database in the user's data directory, outside the project, with each tool call's name, input, status and timestamps recorded as it runs, including MCP tools and sub-agent sessions. Approval decisions are only published as transient events, not stored, and there is no actor attribution or tamper protection; with shell allowed by default the agent can edit or delete the database. Logs are local files.

The agent loop has no step limit by default (agent steps default to unlimited) and there is no cost or session time limit. Shell commands time out after two minutes by default, but the model can pass any larger timeout. Pressing stop aborts the loop and kills the running command's process group. A repeated-identical-call detector asks the user after three repeats, but that is a progress heuristic, not a budget.