OpenCode

Host entry

A terminal command owns the process, current working directory, stdin/stdout, shell environment, and project file discovery.

Host owns

The CLI host owns agent loop timing, approval prompts, tool execution, session files, and how hook or MCP subprocesses are launched.

Connector role

agent-connector can only write the host's documented CLI config, prompt, memory, hook, MCP, or package files and point them at the home binary. Current wired connector surfaces: MCP server, Hooks, Commands, Skills, Subagents, Memory.

Implementation consequence

A CLI surface is byte-addressable and smoke-testable from a temporary HOME, but terminal UI behavior still belongs to the host process. No visible host-native gap is currently tracked for this surface.

Source pass

Current source review findings are kept as the first architecture section so readers can separate external evidence from the generated local coverage model.

• OpenCode is treated as the canonical ts-plugin architecture for this project: a generated plugin bridge is the hook boundary instead of a spawned JSON-stdio command.
• The source target is open and active, so fork-lineage hosts such as Kilo CLI and MiMoCode can be compared against OpenCode before claiming divergence.
• Because the plugin bridge is a runtime integration, marketplace delivery is tracked separately from the hook paradigm.

Runtime boundary

OpenCode loads a generated TypeScript plugin bridge rather than spawning a JSON-stdio hook command. The host owns the TUI, server, model provider, tool permissions, and session loop; the bridge maps host plugin events back to the stable agent-connector home binary.

• The public docs describe OpenCode as available through a terminal interface, desktop app, or IDE extension.
• agent-connector keeps this adapter row scoped to the CLI/plugin file target so multi-surface product identity does not collapse the host-specific install path.

MCP registration

OpenCode config explicitly includes MCP servers in the schema. The adapter must render OpenCode's JSON/JSONC config shape and respect config precedence rather than reuse another host's MCP dialect.

• OpenCode config sources include remote, global, custom, project, `.opencode` directories, inline, managed files, and macOS managed preferences.
• Later config sources override earlier conflicts while preserving non-conflicting settings, so direct writes need to be scoped carefully.

Hook bridge

Plugins are OpenCode's hook boundary. Local JavaScript or TypeScript files under `.opencode/plugins/` or global config plugins can subscribe to events; npm plugins are configured separately and cached by the host.

• Plugin modules export functions that receive project, client, shell, directory, and worktree context.
• The plugin docs show event hooks such as tool execution interception, which maps naturally to a TypeScript bridge.
• Plugin load order separates global config, project config, global plugins, and project plugins.

Content surfaces

OpenCode's `.opencode` and global config directories include plural subdirectories for agents, commands, plugins, skills, tools, themes, and modes. These are durable host-native content surfaces rather than ad hoc generated files.

• Agent configuration supports role-specific prompt files, model choices, temperatures, and step limits.
• OpenCode creates or reads AGENTS.md-style project memory during initialization.
• Commands and skills should be documented as content surfaces separate from the plugin hook layer.

Marketplace and host-only affordances

OpenCode can load npm plugin packages and local plugin files, so marketplace delivery and direct generated-plugin writes are both relevant. The adapter should distinguish drivable package install from direct bridge generation.

• npm plugins are installed automatically at startup and cached under the host cache directory.
• The host also exposes sharing, web, IDE, GitHub, GitLab, permissions, LSP, and ACP support as product affordances outside the core connector surfaces.

Host-specific shape

OpenCode is the canonical ts-plugin host: the generated plugin bridge is the hook boundary and the same adapter owns MCP, commands, skills, subagents, and memory artifacts.

• Form factor: CLI.
• Native surfaces: MCP server, Hooks, Commands, Skills, Subagents, Memory.
• Wired surfaces: MCP server, Hooks, Commands, Skills, Subagents, Memory.
• Visible gaps: none.

Hooks

Hooks enter through a generated plugin module that the host loads in its own runtime.

MCP

The adapter writes this host's native MCP registration dialect, including its root key, scope, transport fields, and environment syntax.

Memory

Managed memory text is written into the rules or memory file this host actually reads, with ownership markers for reversible uninstall.

Marketplace and affordances

A marketplace or plugin-driver path is wired, so install/update/uninstall can be driven rather than only emitted as files.

• Runtime handlers: none.
• User-visible affordances: Users see managed commands + skills + subagents + memory surfaces after install; runtime-only surfaces stay behind the host boundary..