Kilo Code

Host entry

An IDE extension host runs inside VS Code, JetBrains, or another editor and receives workspace/editor context through that host's extension APIs.

Host owns

The editor owns activation, command palette placement, sidebar/chat UI, extension storage, trust prompts, and workspace permission boundaries.

Connector role

agent-connector targets documented extension-readable config, MCP, commands, skills, rules, and memory files without claiming control of the IDE. Current wired connector surfaces: MCP server, Hooks, Commands, Skills, Subagents, Memory.

Implementation consequence

Extension surfaces must distinguish file-backed connector artifacts from UI affordances that only the editor or marketplace extension can expose. 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.

• Kilo is presented as an agentic engineering platform, and the same repository backs both the VS Code extension and Kilo CLI rows.
• The extension row is therefore linked to Kilo's shared backend conventions, while form factor metadata keeps it separate from the CLI adapter id.
• Because Kilo Code and Kilo CLI share source lineage, marketplace and ts-plugin claims must be scoped to the specific adapter id shown on the page.

Runtime boundary

The current adapter row is an extension surface, while the public product spans VS Code, JetBrains, and CLI. agent-connector should show Kilo as multi-surface host nature without assuming all surfaces share one writable configuration model.

• The README presents Kilo Code as available in VS Code, JetBrains, and CLI.
• The CLI is described as forked from OpenCode, which is architecture evidence but not proof of identical file paths.
• Cloud Agent and review surfaces are host workflows outside the local extension runtime.

MCP registration

Kilo advertises an MCP marketplace, so MCP should be treated as a first-class extension path. The connector must still identify whether a server is registered through the VS Code extension, JetBrains plugin, CLI, or cloud surface before claiming implementation.

• Marketplace-backed MCP is a distribution concern as well as a tool registration concern.
• A multi-IDE host can expose the same conceptual MCP feature through different storage layers.

Hook bridge

The current connector matrix treats Kilo as a TypeScript-plugin style host. Hook documentation should describe the extension/plugin bridge and avoid assuming the same hook contract applies to the CLI fork or cloud agent until those runtimes are tested separately.

• Plugin host events and local CLI events are separate runtime boundaries.
• Autonomous mode and code review automation are host behaviors, not necessarily connector hook events.

Content surfaces

Kilo's public modes include Code, Plan, Ask, Debug, and Review, and the product also advertises custom workflow features. The page should show those as host-native content surfaces while keeping agent-connector skills, commands, and memory tied to verified adapter paths.

• Mode names are a useful teaching bridge between editor UX and agent architecture.
• KiloClaw and cloud-agent naming should be represented as host affordances, not generic connector subagents.

Marketplace and host-only affordances

Kilo's MCP marketplace, multi-IDE distribution, CLI lineage, cloud agent, and code-review surfaces make it a strong example of product-family architecture. The coverage matrix needs to show which of those are host-native versus agent-connector implemented.

• VS Code, JetBrains, and CLI should remain visible as separate surface labels.
• The OpenCode lineage is relevant to plugin architecture but should not replace Kilo-specific source review.

Host-specific shape

Kilo Code is the VS Code extension sibling of Kilo CLI: it shares the Kilo backend conventions and uses a ts-plugin bridge with MCP, commands, skills, subagents, and memory.

• Form factor: Extension.
• 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..