[stamp-build]

^{Cindy from open-agent-runtime opened this pull request through Stamp
View in Stamp →}

---

Minor release: OpenCode no longer shares one process between sessions. Every auto open of opencodeRuntime now starts its own process again, on every version and platform, including OpenCode 2.2.3 (shared since 0.81.0) and 2.2.5 (shared since 0.82.0). No native runtime shares a process in this release.

Behavior changes for hosts

OpenCode shared placement is withdrawn (#587)

• Under auto, the default, every OpenCode session opens its own process, and Session.placement reports isolated. They behave like any other isolated session: disposal and the abort fallback record exited, never released, so later controls are not rejected session_released; resources() describes the session's own process, without scope: "shared_process" (and stays null on Windows); and the [oar:opencode:shared] stderr summaries no longer appear.
• An explicit shared request is refused with UnsupportedOptionError (option: "placement") on every version and platform. Its message names configured plugins as the reason; match on option, not on the text.
• Hosts that select runtime.execution === "process" ? runtime.withPlacement("isolated") : runtime, as Raft, Ferry and rowrow do, see no change.

Why: OpenCode loads plugins from user and project configuration, and a plugin can start its own child processes. A plugin that starts a child without setting a working directory gets the OpenCode process's working directory. In a shared process that is the shared process's home directory; in a separate process it is the session's directory. We observed this with user-level and project-level plugins whose tool execute.before hook starts a child, on OpenCode 2.2.3 and 2.2.5 (Linux x64): in all four shared runs the child ran in the home directory, and in all four isolated runs it ran in the session directory. OpenCode's shell tool ran in the session directory in both modes. OAR cannot tell before a session opens which plugins its configuration loads, so it cannot pick out sessions that are safe to share (evidence).

The shared-process rules now require that tools, stdio MCP servers and hooks started for a session get the working directory and environment they would have in a separate process, and that a runtime version whose sessions may use them without OAR being able to tell beforehand does not share (#586). Grok, whose sharing was never released, also stays unadmitted.

The shared-process code stays in the repository for experiments, but no public export reaches it: opencodeRuntime, withPlacement(), opencodeSession and defaultRuntimes all go through the refusal or the isolated path.

Docs

• The design rules for shared processes add the child-process environment requirement and record that no native runtime is currently enabled for sharing; the placement contract, the OpenCode runtime page and the development guide no longer describe OpenCode as shared (docs(design): require session-equivalent child process environment for sharing #586, fix(opencode): withdraw shared placement after plugin cwd counterexample #587, docs(opencode): remove stale shared-placement statements after withdrawal #588).

Tests and CI

• The check job no longer runs the OpenCode shared behavior suite or the real shared and isolated lifecycle checks. It still installs OpenCode 2.2.5 for the real isolated tool-cleanup check. Those checks, plus a new plugin child-environment comparison, run against an experimental adapter outside the package in a manual OpenCode sharing experiment workflow (opencode-sharing-experiment.yml, all three platforms by default) (fix(opencode): withdraw shared placement after plugin cwd counterexample #587).
• A new test, with a scripted agent, opens two auto sessions for installations reporting 2.2.3, 2.2.5 and 2.2.6, one with no MCP servers and one with only an HTTP MCP server. It checks that each is isolated with its own process, and that explicit shared is refused on placement with a message naming configured plugins (fix(opencode): withdraw shared placement after plugin cwd counterexample #587).

🤖 Generated with Claude Code