[FEATURE]: Allow disabling built-in MCP servers (chrome-devtools, morphllm-fast-apply) #22188

Problem

OpenCode bundles chrome-devtools and morphllm-fast-apply as default/hardcoded MCP servers. They are spawned on every session startup even when the user's opencode.json contains no reference to them. There is currently no supported configuration mechanism to disable them.

This forces all users to pay the token and process overhead for tools they may never use.

Evidence

1. Official repo treats chrome-devtools as a built-in default

Merged PR #15516 discusses orphaned child processes from chrome-devtools-mcp and provides an example config that assumes chrome-devtools is a default server every user has:

"chrome-devtools": {
  "type": "local",
  "command": [
    "npx", "-y", "chrome-devtools-mcp@latest",
    "--userDataDir={env:HOME}/.cache/chrome-devtools-mcp/{env:OPENCODE_PID}"
  ]
}

This PR was merged. It does not describe how a user adds chrome-devtools; it describes how to reconfigure an already-present built-in.

2. morphllm-fast-apply is documented as an integrated ecosystem plugin

Issue #1591 (closed) requested MorphLLM integration as a first-class editing engine, and later issue #16632 (closed) updated the ecosystem docs to point users to the Morph plugin. The tool is surfaced automatically without explicit user configuration.

3. opencode.json has never contained these MCPs

The oldest backup of my ~/.config/opencode/opencode.json shows:

"mcp": {}

The current file contains only user-defined servers:

"mcp": {
  "gsd": { ... },
  "openmemory": { ... }
}

No chrome-devtools, morphllm-fast-apply, or claude-mem:mcp-search entries exist.

4. Startup logs show them loading independently of configuration

From ~/.local/share/opencode/log/2026-04-11T163029.log (pre-sandbox):

INFO  service=mcp key=chrome-devtools type=local found
INFO  service=mcp key=morphllm-fast-apply type=local found
INFO  service=mcp key=claude-mem:mcp-search type=local found

These lines appear even though opencode.json had no such keys at the time.

5. Attempting to disable via opencode.json fails schema validation

Adding the natural-looking config:

"chrome-devtools": {
  "type": "local",
  "command": ["true"],
  "enabled": false
}

Produces a fatal validation error on session attach:

Error: Configuration is invalid at /home/imax/.config/opencode/opencode.json
↳ Invalid input mcp.chrome-devtools

(Note: opencode mcp list accepts the entry silently and shows it as disabled; the fatal error only surfaces in the opencode -s <session> attach path, indicating inconsistent validation depending on which code path parses the config.)

6. Public JSON Schema does not declare an mcp field

The $schema referenced by opencode.json (https://opencode.ai/config.json) has no top-level mcp property in its published schema. MCP validation is performed by a private zod schema inside the binary, which rejects built-in names because they are not valid user-defined server configs.

$ curl -s https://opencode.ai/config.json | jq 'has("mcp")'
false

7. claude-mem:mcp-search comes from a different source (.claude/ compatibility layer)

Pre-sandbox logs showed claude-mem:mcp-search type=local found even after it was removed from ~/.claude/settings.json's enabledPlugins. After wrapping opencode in a bwrap sandbox that hides ~/.claude, the log entries disappeared. This proves OpenCode scans ~/.claude/ independently of Claude Code's own settings.

chrome-devtools and morphllm-fast-apply, however, are not blocked by the sandbox — they continue to load because they originate from the opencode binary itself rather than the filesystem.

Why existing issues do not cover this

• Disabling MCPs doesn't persist across sessions #13763 (Disabling MCPs doesn't persist across sessions) is about UI toggle persistence for user-configured MCPs. It does not address MCPs that are born inside the binary and therefore never appear in any toggle list in the first place.
• [FEATURE]: No way to start SDK server without loading user MCP servers #20072 (No way to start SDK server without loading user MCP servers) provides a XDG_CONFIG_HOME hack for SDK callers. It does not solve the problem for end users running the TUI or desktop app who need built-in MCPs disabled by default.

Proposed Solutions (in order of preference)

1. disabled_mcp_servers array in opencode.json

   {
     "disabled_mcp_servers": ["chrome-devtools", "morphllm-fast-apply"]
   }

2. Respect mcp.<name>.enabled: false for built-ins
   If a built-in name appears with enabled: false, skip spawning instead of raising Invalid input.

3. Environment variable override
   OPENCODE_DISABLE_BUILTIN_MCPS=chrome-devtools,morphllm-fast-apply

Impact

• Token overhead: Each bundled MCP injects tool definitions into the context window. On 128k models this consumes prompt budget before the first user message.
• Security/attack surface: chrome-devtools launches a browser process; morphllm-fast-apply pulls and executes remote npm code. Users who do not use these features are forced to accept the risk.
• Config confusion: The current behavior breaks the expectation that opencode.json is the source of truth for what MCPs are active.

Environment

• OpenCode version: 1.4.3
• OS: Linux (ARM64, Debian-based)
• Shell: bash