fix: Fix environment variable configuration for opencode MCPs

[DMarby]

This PR fixes environment variable handling when reading/writing opencode MCP configuration: opencode expects environment, but we were setting env. Additionally, it doesn't support setting either for remote MCPs. See McpLocalConfig and McpRemoteConfig on https://opencode.ai/config.json for reference

[greptile-apps]

Greptile Summary

This PR corrects the field name used for environment variables when writing opencode MCP configuration: local (stdio) servers now correctly emit environment instead of env, and remote servers no longer receive an unsupported env field at all. The reverse adapter is updated symmetrically to translate environment back to the canonical env key.

• fwdOpencode: replaces entry.env = v.env with entry.environment = v.env for local servers, and removes the env assignment entirely for remote servers (opencode's McpRemoteConfig does not accept it).
• revOpencode: adds a new guard to read v.environment from a local entry and map it back to entry.env in canonical form.
• Tests: two new cases cover forward environment emission and reverse environment→env translation for local servers; no test documents the intentional silent drop of env on remote servers.

Confidence Score: 4/5

Safe to merge; the core field-name fixes are correct and well-tested for the local/stdio case.

The local-server env→environment rename and its reverse are correct and covered by new tests. The only gap is that env vars on remote/HTTP servers are now silently discarded with no comment or test to communicate that this is intentional — a developer unfamiliar with the opencode schema could interpret this as a data-loss regression rather than a deliberate omission.

The remote-server branch in fwdOpencode (adapters.ts ~line 102) is the spot worth a second look — it is where env vars are dropped without documentation.

Important Files Changed

Filename	Overview
src/main/core/mcp/utils/adapters.ts	Fixes opencode env-var field name (env → environment for local servers) and removes the unsupported env field from remote server entries; the forward path drops env vars on remote servers silently with no comment or test to document this intentional data loss.
src/main/core/mcp/utils/adapters.test.ts	Adds two targeted tests covering the new environment key mapping in both forward and reverse directions; coverage is correct, though there is no test for the intentional silent drop of env vars on remote/HTTP servers.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Canonical ServerMap] -->|adaptForward opencode| B{Server type?}
    B -->|isHttpServer| C[Build remote entry\ntype: remote, url, headers, enabled]
    C -->|env dropped — not supported by McpRemoteConfig| D[Remote entry output]
    B -->|isStdio| E[Build local entry\ntype: local, command array, enabled]
    E -->|v.env → entry.environment| F[Local entry output]
    B -->|other| G[deepClone as-is]

    H[Opencode ServerMap] -->|adaptReverse opencode| I{v.type?}
    I -->|remote| J[Destructure type + enabled\nspread rest → type: http\nstripInjectedHeaders]
    I -->|local| K[Split command array\ncommand + args]
    K -->|v.environment → entry.env| L[Canonical stdio entry]
    I -->|other| M[deepClone as-is]

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
src/main/core/mcp/utils/adapters.ts:102-103
**Silent env-var drop on remote servers**

When a canonical HTTP server carries an `env` map, `fwdOpencode` now silently discards it (the old `entry.env = v.env` line was removed). On the next `adaptReverse` round-trip those vars will be absent from the canonical record, so a user who had environment variables stored against an HTTP/remote MCP will permanently lose them after the first save. A short inline comment (e.g. `// opencode McpRemoteConfig does not support environment vars`) and a matching test case documenting this intentional loss would prevent future confusion about whether the drop is intentional.

_{Reviews (1): Last reviewed commit: "fix: Fix environment variable configurat..." | Re-trigger Greptile}

[greptile-apps]

Silent env-var drop on remote servers

When a canonical HTTP server carries an env map, fwdOpencode now silently discards it (the old entry.env = v.env line was removed). On the next adaptReverse round-trip those vars will be absent from the canonical record, so a user who had environment variables stored against an HTTP/remote MCP will permanently lose them after the first save. A short inline comment (e.g. // opencode McpRemoteConfig does not support environment vars) and a matching test case documenting this intentional loss would prevent future confusion about whether the drop is intentional.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/main/core/mcp/utils/adapters.ts
Line: 102-103

Comment:
**Silent env-var drop on remote servers**

When a canonical HTTP server carries an `env` map, `fwdOpencode` now silently discards it (the old `entry.env = v.env` line was removed). On the next `adaptReverse` round-trip those vars will be absent from the canonical record, so a user who had environment variables stored against an HTTP/remote MCP will permanently lose them after the first save. A short inline comment (e.g. `// opencode McpRemoteConfig does not support environment vars`) and a matching test case documenting this intentional loss would prevent future confusion about whether the drop is intentional.

How can I resolve this? If you propose a fix, please make it concise.