Summary

Environment variable substitution using {env:VAR_NAME} syntax works for some remote MCP servers but fails for others, even when using identical configuration patterns.

Environment

• OS: macOS (darwin)
• OpenCode version: Latest (installed via npm)
• Shell: zsh
• Config location: ~/.config/opencode/opencode.jsonc

Steps to Reproduce

1. Configure two remote MCP servers with the same {env:...} pattern in opencode.jsonc:

"mcp": {
  "exa": {
    "type": "remote",
    "url": "https://mcp.exa.ai/mcp?exaApiKey={env:EXA_API_KEY}",
    "enabled": true
  },
  "tavily": {
    "type": "remote",
    "url": "https://mcp.tavily.com/mcp?tavilyApiKey={env:TAVILY_API_KEY}",
    "enabled": true
  }
}

2. Export both environment variables in ~/.zshrc:

export EXA_API_KEY=<valid-key>
export TAVILY_API_KEY=<valid-key>

3. Start OpenCode from a terminal where both env vars are confirmed to be set.
4. Invoke both MCP tools.

Expected Behavior

Both MCP servers should receive the API key and work correctly, since the configuration pattern is identical.

Actual Behavior

• Exa MCP: Works correctly. API key is substituted and requests succeed.
• Tavily MCP: Fails with {"error":"Search failed","detail":"API key is required"}.

Additional Testing

Possible Cause

There may be an issue with how OpenCode caches or resolves {env:...} substitutions for specific MCP server names or URLs. The inconsistency between Exa (working) and Tavily (not working) with identical patterns suggests a bug in the variable substitution logic.

Workaround

Just hardcoding the API key directly in the URL works, but this is not ideal for security reasons.

OpenCode version

1.0.137

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response