OpenCode is a multi-surface coding agent
OpenCode is an open-source coding agent that does not live in a single place. It runs in the terminal, as an IDE extension, and as a desktop app, supports parallel agent sessions on the same project, and connects to a large range of model providers. It is, in the vocabulary we use for this stack, a harness — the execution layer that coordinates tool calls, state, and the agent loop across more than one surface.
That breadth is exactly why governance matters here. The more surfaces an agent acts through, the more places an architectural decision can quietly fail to apply. A rule enforced in the terminal but not in the desktop app is not a rule.
OpenCode coordinates execution across surfaces. A Mneme plugin would enforce the same architectural intent on every surface — that is the goal of this experimental integration.
The proposed integration surface: OpenCode's plugin hooks
OpenCode exposes a plugin system with hooks at the points where governance belongs. A Mneme plugin, installed under .opencode/plugins/, would register on these hooks and run mneme check against the team’s recorded decisions, returning explainable PASS, WARN, or FAIL findings — each carrying the decision id that produced it. No such plugin ships today. The table below is the design under evaluation, not a description of shipped behaviour.
| OpenCode hook | Mneme action (proposed) | Mode (proposed) |
|---|---|---|
| tool.execute.before | Check the proposed change against decisions before it runs | Advisory or blocking |
| tool.execute.after / file.edited | Verify the change that landed; surface violations with the decision id | Advisory |
| session.idle | Run a governance pass over the session's changes | Advisory |
| before git commit / push | Block changes that violate a recorded architectural decision | Blocking |
| session compaction | Status: evaluated and closed — the completed experiment returned a NULL verdict (no measurable effect). Not a shipped capability. | Context |
Advisory at the edit, blocking at the boundary (design intent)
In the proposed design, enforcement mode depends on the surface. While an agent is editing, an advisory check keeps flow intact — it surfaces a finding and the decision behind it without halting work. At the boundaries that matter — before a commit, before a push — a blocking check would refuse to let a change that violates an architectural decision proceed. This mirrors how Mneme works elsewhere: governance before the change lands, with strict enforcement reserved for the points of no return. Until a plugin ships and is validated, treat this as design intent rather than documented behaviour.
Compaction: evaluated, closed as NULL
OpenCode documents compaction hooks designed to preserve task state, decisions, modified files, and multi-agent dependencies across longer sessions. We ran a controlled experiment injecting governance summaries through compaction; it completed with a NULL verdict — no measurable effect on outcomes — and was closed evidence-only, without adoption. The distinction at the heart of Mneme still stands: the difference between remembering a decision and enforcing it. But we will not claim a compaction-based context capability that validation did not support.
Where this sits in the stack
OpenCode is the harness; Mneme is the governance layer that would run alongside it. They are different layers of the runtime stack and they compose: OpenCode decides how the agent executes across terminal, IDE, and desktop, and Mneme decides whether the resulting changes respect the architecture. Today that composition is a validated possibility on other surfaces (Claude Code, Claude Agent SDK, Google Antigravity) and a design under evaluation here. The full argument for why a capable harness still needs this layer is in Harness Engineering Still Needs Governance.
Status: experimental. No production Mneme plugin for OpenCode exists today. If you need enforcement now, use a supported native integration or a CI gate.