Full host-surface analysis across CLI, desktop, and extension form factors. The host is the primary architecture boundary; current external docs and source links checked 2026-07-06 to 2026-09-07 are reconciled with the local adapter registry, SPI contract, and drift-tested capability matrix.
The installer writes native files; the host still owns the agent loop, approval UI, model context, and MCP client. Runtime hooks only exist on json-stdio and ts-plugin hosts.
The installer resolves the target host and loads exactly one adapter implementation.
Native host files
The adapter renders MCP config, hook/plugin registration, and content files in host-native dialects.
Host runtime
The CLI owns model context, approvals, MCP calls, and any lifecycle event that can trigger a hook.
Archive map
Five architecture axes to study per host
This map is the archive's reading order. It keeps runtime interception, tool registration, persisted memory, plugin delivery, and UI affordances separate so implementation work can target the right layer.
Lifecycle hooks
Where the host lets outside code observe or change the agent loop. JSON-stdio hosts launch commands; ts-plugin hosts load generated modules; mcp-only hosts have no confirmed hook boundary.
A valid MCP server can still be misinstalled if the host expects a table, array, object map, YAML document, or nested key that differs from another host.
Memory and rules
Host memory is usually a user-authored rules file. agent-connector must write only its managed block, preserve user text, and uninstall cleanly.
Memory files are shared authoring surfaces, so forced overwrites, hash drift, and project-vs-user precedence matter more than on generated files.
Marketplace and plugin delivery
Marketplace install is a distribution path, not a runtime capability. It stages a package, drives the host's installer where available, and probes host state.
Some hosts expose affordances only through cloud UI, inline config, built-ins, or experimental APIs. Those stay marked as gaps until there is a writable contract.
Reader guide
How to read this archive
The page is meant for people studying host architecture, not just checking support. It separates runtime hooks, MCP configuration, memory files, marketplace delivery, and host-only affordances.
Hooks
Runtime interception is not one feature. JSON-stdio hosts spawn a command with event JSON; ts-plugin hosts load a generated module; mcp-only hosts expose no installable lifecycle boundary.
MCP
MCP is portable at the protocol level but not at the file level. Each adapter renders the host's root key, transport fields, scope, and enablement dialect.
Memory
Memory means writing managed blocks into the rules file the host actually reads. These files are user-authored, so ownership markers and non-clobber behavior matter.
Marketplace
Marketplace/plugin delivery is a distribution path, separate from runtime surfaces. A host can have hooks without a drivable marketplace, or marketplace install without extra runtime power.
Host-only affordances
Status lines, actions, subagents, skills, and cloud-managed prompts are host-specific. The archive calls out when they are wired, host-native gaps, or intentionally left unwired.
Archive assurance
What this archive covers now
These checks summarize the current archive shape before you drill into host cards or individual pages.
Host scope
42 hosts
Every platform entry feeds the study cards, ledger rows, detail routes, and per-host diagrams.
Run type split
30 CLI / 9 Desktop / 4 Ext
1 host keeps multiple run surfaces visible instead of collapsing to one label.
Source review
42/42 checked
Each checked host links to an external source or product page and renders source review notes on its detail page.
Feature inventory
42/42 complete
Each host inventory separates hooks, MCP, memory, marketplace delivery, and host-only affordances.
Paradigms
The three host runtime shapes
These diagrams are derived from the local adapter SPI and representative implementations across CLI, desktop, and extension hosts, then cross-checked against current host docs or source where the host publishes them.
json-stdio
23 CLI
The host owns the agent loop and launches a command for lifecycle events. agent-connector receives host JSON on stdin, normalizes the event, runs the connector handler, and writes the host-native reply envelope.
Each host has different event names and response envelopes, so adapter tests must prove parse/format behavior rather than only checking that files exist.
The host exposes server registration and selected content surfaces, but no lifecycle hook bridge. agent-connector installs what the host can read and reports hook gaps honestly.
A host can be powerful without hooks. The page keeps MCP/content support separate from runtime interception so gaps are visible instead of implied away.
The host loads a generated plugin module. That bridge stays tiny and shells out to the same stable home binary instead of importing arbitrary connector code into the host process.
Plugin hosts can mutate objects in-process; the bridge must avoid version skew, cwd leaks, and dependency coupling by keeping connector code outside the host runtime.
Hosts: OpenCode, MiMoCode, Kilo CLI, Kilo Code, Amp, Oh My Pi (OMP), NVIDIA NemoClaw, OpenClaw
Code evidence
Local code paths that define the architecture
This page intentionally treats code as primary evidence for what agent-connector actually installs today.
Deep references are the architecture-specific docs reviewed for the page. The ledger records every host source, source-review date, and finding count used by the matrix.