OpenCode 1.17.16 drops mcp.<name>.env from resolved config, causing MCP servers to miss environment variables #36434

Activity

1. github-actions

   assigned

   jlongster

   on Jul 11, 2026
2. github-actions commented on Jul 11, 2026

   

   github-actionsBot

   on Jul 11, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • MCP local server env block not propagated to child process #30892: Same root bug — mcp.<name>.env block not propagated to the spawned child process (reported in v1.16.0, still open)
   • [BUG]: customize-opencode skill example for local MCP uses env but schema/runtime expect environment #35860: Related — the config schema uses environment (not env) for local MCP servers, and the runtime merges mcp.environment into the child process env; env is silently dropped as an unknown key

   The env → environment field naming discrepancy described in #35860 may be the direct cause of what you're seeing: if the correct field name is environment, renaming it in your config may resolve the issue while the underlying bug is tracked.
3. Gelly52

   closed this as completedon Jul 13, 2026
4. Gelly52

   reopened this on Jul 13, 2026
5. Gelly52 commented on Jul 13, 2026

   

   Gelly52

   on Jul 13, 2026

   Author

   More actions

   Confirmed — renaming env → environment in my opencode.json fixed it.

   Before:

   "grok-search": {
     "type": "local",
     "command": ["uvx", "--from", "git+https://github.com/GuDaStudio/GrokSearch@grok-with-tavily", "grok-search"],
     "enabled": true,
     "env": {
       "GROK_API_URL": "...",
       "GROK_API_KEY": "..."
     }
   }

   → silently dropped, opencode debug config showed no env at all.

   After:

   "grok-search": {
     "type": "local",
     "command": ["uvx", "--from", "git+https://github.com/GuDaStudio/GrokSearch@grok-with-tavily", "grok-search"],
     "enabled": true,
     "environment": {
       "GROK_API_URL": "...",
       "GROK_API_KEY": "..."
     }
   }

   → opencode debug config now shows the full environment block, and the MCP tool reports config_status: fully configured.

   This is the same root cause as #30892 and #35860 — the built-in customize-opencode skill docs use env, but the actual schema/runtime expects environment, and the config loader silently drops unknown keys instead of erroring. Feel free to close this as a duplicate of #35860 (which already has a fix PR, #35867, for the docs). Thanks for the pointer!
6. hazlamahedich commented on Jul 20, 2026

   

   hazlamahedich

   on Jul 20, 2026

   More actions

   Confirming this still reproduces in 1.18.0 (upgraded from 1.17.16 where I first saw it).

   opencode debug config drops the env block on every mcp.<name> entry — even for servers that have no env in the source file, so it's not just a redaction artifact. For servers that do require env vars, the spawned child genuinely never receives them, which I confirmed with a logging wrapper:

   #!/bin/bash
   { echo "PEXELS_API_KEY len: ${#PEXELS_API_KEY}"; } >> /tmp/invocation.log
   exec npx -y mcp-pexels

   → PEXELS_API_KEY len: 0 when opencode launches it (the value is present in opencode.json). open-design fails the same way because ELECTRON_RUN_AS_NODE=1 is dropped, so the Electron Helper tries to launch as a GUI app and the stdio MCP handshake dies with -32000 Connection closed.

   Two of the three affected servers (pexels, open-design) report MCP error -32000: Connection closed, not a missing-config error — so this may be part of why the issue is under-diagnosed: failures look like protocol/transport bugs rather than an env regression.

   Workaround that works reliably on 1.18.0: point the command at a small wrapper script that exports the env vars itself before exec-ing the real server. Local MCP servers are then fully functional.
7. jond34 commented on Jul 29, 2026

   

   jond34

   on Jul 29, 2026

   More actions

   Cross-linking: I filed #39431 for the underlying validation gap that makes this class of bug silent.

   Verified on 1.18.9, the inconsistency is one level of nesting:

   • unknown key at config root → Error: Configuration is invalid ... ↳ Unrecognized key: <name>
   • same unknown key nested inside mcp.<name> → silently discarded, no error, no warning, server reports healthy

   So env (vs environment) is stripped with no diagnostic. @Gelly52 your read that "the config loader silently drops unknown keys instead of erroring" is exactly right, and @hazlamahedich the opaque -32000 Connection closed is the downstream symptom of that.

   Worth noting the docs half is now fixed — the bundled customize-opencode skill says environment in 1.18.9 (it said env in 1.18.5, per #39135). But the silent-drop behavior is unchanged, so configs written against the older skill keep failing silently after upgrade. Homebrew is also still shipping 1.18.5, so new brew users still get the skill that teaches the stripped key.

   In my case this silently loaded a different dbt-mcp toolset than configured — every DISABLE_* flag ignored, and write tools exposed despite being explicitly disabled, while the server reported healthy. Details in #39431.
8. github-actions commented on Sep 27, 2026

   

   github-actionsBot

   on Sep 27, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
9. github-actions

   closed this as not plannedon Sep 27, 2026