You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unknown keys at the root of opencode.json are rejected with a clear ConfigInvalidError. Unknown keys nested inside an mcp.<name> object are
silently discarded — no error, no warning, no log line. The server starts and
reports healthy.
This inconsistency is the actual footgun behind the recurring env vs environment reports (#36434, #30892, #35860, #39135, #26332, #35867). Those
are about the correct key name. This issue is about the missing validation
that makes any such mistake silent. Correcting the docs does not fix it — see
"Why this survived the docs fix" below.
Identical results via OPENCODE_CONFIG and via project-local ./opencode.json.
Expected
mcp.<name> should reject or warn on unrecognized keys, consistent with root.
The message at root (Unrecognized key: …) is already exactly right — it just
isn't applied to nested objects.
Why this survived the docs fix
The customize-opencode skill in 1.18.5 documents the key as env:
In 1.18.9 it correctly says environment (thanks — #39135). But the
silent-drop behavior is unchanged, so every config written against the older
skill keeps failing silently after upgrade, with nothing to point at the cause.
Note Homebrew is still shipping 1.18.5 (homebrew-core formula), so new brew users are currently being handed the version whose bundled skill teaches
the key that gets silently stripped.
Confirmed on 1.18.9 with a stub MCP server that dumps its own environment: "env": { "T_VIA_ENV": "should_be_set" } → server receives <UNSET>, and no
warning is emitted. The child does inherit opencode's own environment, so the
symptom presents as "my env var isn't set" rather than "my config key is
wrong", which is what makes it hard to diagnose. (#36434 shows it surfacing as
an opaque -32000 Connection closed instead.)
Why it matters beyond a typo
Configuring dbt-mcp with env instead of environment silently loaded a different toolset than specified:
every DISABLE_* flag ignored, so dbt Platform toolsets loaded instead of the
intended dbt Core CLI toolset
write tools trigger_job_run, cancel_job_run, retry_job_run exposed
despite being explicitly disabled
DISABLE_TOOLS=build,run,test,clone ignored
the intended CLI tools absent entirely, because the missing DBT_PROJECT_DIR
made dbt-mcp auto-disable them
The server reported healthy throughout. A user can reasonably believe they have
a read-only server while write tools are live. For anyone pointing MCP servers
at production data, that's a meaningful failure mode.
Summary
Unknown keys at the root of
opencode.jsonare rejected with a clearConfigInvalidError. Unknown keys nested inside anmcp.<name>object aresilently discarded — no error, no warning, no log line. The server starts and
reports healthy.
This inconsistency is the actual footgun behind the recurring
envvsenvironmentreports (#36434, #30892, #35860, #39135, #26332, #35867). Thoseare about the correct key name. This issue is about the missing validation
that makes any such mistake silent. Correcting the docs does not fix it — see
"Why this survived the docs fix" below.
Reproduction
opencode 1.18.9 (darwin-arm64), macOS 26.1.
A. Unknown key at root — correctly rejected
{ "$schema": "https://opencode.ai/config.json", "totally_bogus_root_key_xyz": { "a": 1 } }B. Unknown key nested in
mcp.<name>— silently accepted{ "$schema": "https://opencode.ai/config.json", "mcp": { "x": { "type": "local", "command": ["/bin/echo"], "enabled": false, "totally_bogus_nested_key_xyz": { "a": 1 } } } }Starts normally. No diagnostic of any kind.
Identical results via
OPENCODE_CONFIGand via project-local./opencode.json.Expected
mcp.<name>should reject or warn on unrecognized keys, consistent with root.The message at root (
Unrecognized key: …) is already exactly right — it justisn't applied to nested objects.
Why this survived the docs fix
The
customize-opencodeskill in 1.18.5 documents the key asenv:In 1.18.9 it correctly says
environment(thanks — #39135). But thesilent-drop behavior is unchanged, so every config written against the older
skill keeps failing silently after upgrade, with nothing to point at the cause.
Note Homebrew is still shipping 1.18.5 (homebrew-core formula), so new
brewusers are currently being handed the version whose bundled skill teachesthe key that gets silently stripped.
Confirmed on 1.18.9 with a stub MCP server that dumps its own environment:
"env": { "T_VIA_ENV": "should_be_set" }→ server receives<UNSET>, and nowarning is emitted. The child does inherit opencode's own environment, so the
symptom presents as "my env var isn't set" rather than "my config key is
wrong", which is what makes it hard to diagnose. (#36434 shows it surfacing as
an opaque
-32000 Connection closedinstead.)Why it matters beyond a typo
Configuring
dbt-mcpwithenvinstead ofenvironmentsilently loaded adifferent toolset than specified:
DISABLE_*flag ignored, so dbt Platform toolsets loaded instead of theintended dbt Core CLI toolset
trigger_job_run,cancel_job_run,retry_job_runexposeddespite being explicitly disabled
DISABLE_TOOLS=build,run,test,cloneignoredDBT_PROJECT_DIRmade dbt-mcp auto-disable them
The server reported healthy throughout. A user can reasonably believe they have
a read-only server while write tools are live. For anyone pointing MCP servers
at production data, that's a meaningful failure mode.
Related
additionalProperties: falsehard-fails (the behaviorthis issue asks to extend downward)
envblock not propagated to child process #30892, MCP local server: env config not passed to spawned child process #26332 — theenv/environmentsymptom reportsenvbut schema/runtime expectenvironment#35860, customize-opencode skill: MCP local config usesenvbut schema requiresenvironment#39135, fix(skill): correct MCP local server env key to environment in customize-opencode #35867 — the docs half, now fixednpmfield silently ignored unlessmodelsis also configured #33888, opencode Agent config is silently ignored — opencode always sends (1.17.7) #32465, compaction.reserved silently ignored for models without limit.input (e.g. GLM-5.2) — revival of #13980 #38835 — same class, other keys silently ignored(
provider.npm, agenttool_choice,compaction.reserved), suggesting thegap is not specific to
mcp