AI Extensions, November 8: when MCP connections can share a workspace boundary
OpenCode 2.2.6 adds opt-in MCP sharing. Matching accounts, protocol revisions, missing roots and indefinite background waits define its limits.
Opening the same MCP server in several projects can leave several copies of its connection running. OpenCode 2.2.6 adds opt-in sharing, but its documentation makes "the same server" a stricter condition than a matching display name. The shared connection also has no roots, which changes what a server can learn about the calling directory.
Today's source review
OpenCode v2.2.6 was published on November 6. The release advertises fewer processes and faster starts with shared MCP connections, and adds controls for scripted runs. Its MIT license permits reuse under its terms. The release date is a maintenance signal, not evidence of safety or suitability. I have not installed this version, timed startup or tested an MCP server with it.
The setup path is an existing OpenCode installation and its MCP configuration, followed by the server's own authentication where needed. The useful change is small enough to review before enabling it broadly: pool defaults to false in the MCP documentation.
What can actually pool
The docs scope sharing to directories within one OpenCode server and to connections using protocol revision 2026-07-28. With pooling enabled, an unset protocol means auto. A server that answers with an older revision, or a connection explicitly set to legacy, keeps one connection per directory.
Remote connections must match the URL, headers, OAuth settings and signed-in account, along with protocol and timeouts. Server names need not normally match, but sign-ins are stored per name; an OAuth server therefore shares only under the same name. Local connections must match their command, environment and working directory too.
A local server can share between directories on the same machine, not directories in a workspace. Cross-project sharing needs a fixed cwd. Without it, OpenCode starts the server in each project's folder and warns that the connections cannot share. Changing a working directory just to obtain pooling would be a poor bargain if the server was meant to see only that project.
Roots and permissions need their own review
A shared connection has no roots, according to the docs. Requests for tool input appear in the directory that made the call. Neither statement promises that the server itself enforces per-project access. My recommendation is to review the server's file access and account scope before choosing a shared connection.
Two projects using the same broad remote account may satisfy the configuration test while having different human expectations about allowed data. Pooling cannot supply missing permission. Keep staging and production credentials separate, and leave pooling off when a server relies on project roots or mutable per-project session state until its behavior has been checked. These are deployment recommendations, not claims of a discovered OpenCode vulnerability.
The following JSON is an intentionally non-runnable review record, not valid OpenCode configuration. It stores decisions without carrying credentials or pretending to enforce isolation.
- Two directories request a server
- Compare connection settings + negotiated protocol
- Share only when eligible; shared connection has no roots
{
"server_role": "public-documentation-search",
"pool_requested": true,
"same_account_scope": "review-required",
"requires_project_roots": "review-required",
"fixed_local_cwd": "not-applicable-to-remote",
"protocol_seen": null,
"approved": false
}
For an authorized trial, use a disposable server and synthetic data. Compare pool-off with pool-on across two directories, then deliberately change one matching condition. Record the negotiated protocol, process or connection count and which directory receives an input request. Try a server that needs roots. Do not infer isolation from a successful tool call. This article proposes that test; it does not report completed results.
Scripted runs can now wait indefinitely
The same release says opencode run waits for background shells, subagents and image jobs started by its prompt, then lets the model respond to their results before exiting. There is no built-in time limit for that wait. A development server or file watcher can keep it open until interruption. The notes say SIGTERM cancels the session and its background jobs and exits with code 143.
For CI I would set an external job timeout and name the expected output before starting. A completed foreground answer is insufficient if the requested artifact still depends on a background job. The release also adds run -w for a new git worktree; it cannot be combined with --continue or --session. --archived keeps scripted sessions out of normal inbox and session lists, so the job's own logs become more important to review.
Where I would start
A read-only documentation server with the same account scope across projects is a reasonable candidate for a small pooling trial. A server that expects project roots deserves a separate test before sharing. For unattended runs, I would review the timeout change even if I never enable pooling. Both decisions depend on the server's actual behavior, which release notes and popularity counts cannot certify.