code mode: execute tool returns null for all code, including thrown errors #62923

Summary

In OpenCode v2.2.6, the Code Mode execute tool returns null for every invocation — plain return values, console.log output, the global search() function, and even code that throws — while the MCP servers it is supposed to expose are healthy and connected. The result/error channel of the Code Mode runtime appears dead in this session.

Environment

• opencode version: opencode v2.2.6 (desktop app /Applications/OpenCode.app 2.2.6; CLI at ~/Library/Application Support/ai.opencode.desktop/cli/2.2.6-arm64/opencode-cli)
• OS: Darwin 27.2.0, macOS arm64
• Terminal: OpenCode desktop app (Electron); spawned shells see TERM=xterm-256color
• Shell: /bin/zsh
• Install/channel: release 2.2.6 ("latest" channel, desktop install); server process runs as opencode-cli serve --service
• Active plugins: none found (no plugin key in ~/.config/opencode/opencode.jsonc — only MCP server entries; no .opencode/ plugin dir in the working directory)
• Working directory: a non-git directory (~/Documents/Default Project); server log shows worktree discovery failed ... Worktree.DirectoryUnavailableError for it

Reproduction

1. Start a session in any directory (reproduced in a non-git project dir).
2. Call the Code Mode execute tool with:

   async function main() { return "hello"; }

3. Observe the tool result: null.
4. Repeat with variations — all return null:
   • async function main() { console.log("x"); return { a: 1 }; }
   • async function main() { throw new Error("test error"); } (no error is surfaced)
   • async function main() { return await search({ query: "jira" }); } (global search also returns null)
   • async function main() { return await tools["<mcp-ns>"].someTool({...}); }
5. Verify MCP health independently — all fine:
   • ps shows the npx-spawned MCP server processes running (jira / confluence / bitbucket / kubernetes MCP servers).
   • Server log (~/.local/share/opencode/log/opencode.log) shows mcp connected server=<jira-dc> tools=34, <bitbucket-dc> tools=21, <confluence-dc> tools=9.
   • Manual stdio JSON-RPC (initialize + tools/list) against the locally spawned JIRA MCP package answers with a valid protocol handshake and tool list.
   • A remote MCP endpoint (internal Jenkins MCP over HTTP) answers initialize correctly.
6. Note: during the session, harness system messages repeatedly announced "The Code Mode tool catalog has changed. This catalog supersedes the previous Code Mode tool catalog." — the null behavior was identical before and after those catalog swaps.

Expected Behavior

execute runs the JavaScript in the confined Code Mode runtime and returns the final expression's value (or surfaces a thrown error), with tools.* bound to the connected MCP tool catalog and search() listing it.

Actual Behavior

Every execute call returns null. No result, no stdout, no error — thrown exceptions are swallowed into null as well, and search(...) inside execute also returns null. Reproducible consistently (10+ calls in one session), not intermittent.

Additional Context

• Server log has no ERROR entries for tools/MCP during the session — only unrelated Failed to fetch models.dev timeouts and the worktree-discovery warnings for the non-git cwd.
• A file under ~/.local/share/opencode/tool-output/ contains a successful MCP (JIRA) response payload, i.e. MCP tool calls can succeed server-side while the execute result channel still returns null to the model — pointing at the Code Mode result propagation, not at MCP connectivity.
• Mid-session Code Mode catalog swaps ("catalog supersedes the previous catalog") are a plausible trigger; the harness, not the local config, changed.
• Workaround used in the affected session: drive the MCP servers manually over stdio (npx + JSON-RPC messages) or call their backing REST APIs directly with the configured credentials; regular shell/ssh/file tools are unaffected.
• Credentials, internal hostnames and tokens from the local MCP config were intentionally redacted from this report.