JetBrains Copilot

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, 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.

• GitHub Copilot's official product page positions Copilot across editor and enterprise workflows, with agents, Copilot CLI, and VS Code explicitly called out.
• The JetBrains row is therefore an IDE integration surface for Copilot, not the Copilot CLI and not the VS Code Copilot extension row.
• Copilot guidance emphasizes developer oversight and review, so agent-connector should avoid treating suggestions as autonomous hook/action execution.

Runtime boundary

The adapter target is the JetBrains plugin environment. JetBrains owns IDE lifecycle, editor APIs, project model, tool windows, plugin settings, and authentication UI, while GitHub owns Copilot service behavior.

• This row is distinct from VS Code Copilot because the extension host and storage model differ.
• It is also distinct from Copilot CLI because the CLI session harness runs outside the IDE.
• The GitHub docs list Copilot in JetBrains as its own agent concept surface.

MCP registration

MCP support for JetBrains Copilot should not be assumed from VS Code Copilot or Copilot CLI. The page should only claim MCP when GitHub or JetBrains documentation exposes a JetBrains-specific configuration path.

• IDE-specific plugin settings may differ from VS Code settings JSON or Copilot CLI config.
• MCP in Copilot cloud or CLI does not automatically imply JetBrains plugin support.

Hook bridge

The current connector matrix treats JetBrains Copilot conservatively. GitHub's broader Copilot platform documents hooks, but a JetBrains plugin hook bridge requires JetBrains-specific implementation evidence.

• GitHub Copilot SDK hooks are not the same as JetBrains plugin hooks.
• Editor actions and tool windows are host UI, not lifecycle hook files.

Content surfaces

JetBrains Copilot content surfaces include IDE chat, code suggestions, project context, GitHub authentication, and potentially custom instructions or agent features as GitHub exposes them to the plugin.

• JetBrains project model and indexing differ from VS Code workspace context.
• Any repository instruction support should be verified through GitHub's IDE-specific docs.

Marketplace and host-only affordances

The host-only affordance is JetBrains Marketplace distribution and deep integration with IntelliJ-platform IDEs. The archive should show it as an extension/IDE host rather than a terminal or GitHub cloud agent.

• Marketplace installation, IDE compatibility, and plugin versioning are central support facts.
• Copilot service features may arrive at different times across JetBrains, VS Code, CLI, and GitHub web.

Host-specific shape

JetBrains Copilot is an IDE-extension host: MCP, json-stdio hooks, commands, skills, and memory are tracked, while subagent, statusline, and action surfaces are not confirmed.

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

Hooks

Hooks enter through a host-launched command that exchanges event JSON over stdio.

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

Current install is a direct native-file write path; any package artifact is manual unless a driver is added.

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