Supported AI agents

Plugin

The plugin runs on AI coding agents that implement both Agent Skills and MCP as open standards. Every host gets the same skills, built-in agents, and MCP tools. Hooks, plugin manifests, and MCP registration differ per host.

Support matrix

Host	Status	Install from the host	Install with the Archcore CLI	MCP wiring	Hook events
Claude Code	Production	Plugin marketplace	Yes, at user scope	Automatic, from the plugin’s .claude.mcp.json (runs archcore from PATH)	SessionStart, PreToolUse, PostToolUse
Cursor	Implemented	Plugin marketplace or local directory	No. Cursor manages plugins in its UI, so the CLI prints the instruction and runs no command	User-registered from the docs/cursor.mcp.example.json template, scoped with --project ${workspaceFolder}	sessionStart, preToolUse, afterMCPExecution
Codex CLI	Implemented	codex plugin marketplace add	Yes, machine-level rather than per project	Automatic, from the plugin’s .codex.mcp.json (runs archcore from PATH)	SessionStart, PreToolUse, PostToolUse, behind a feature flag
GitHub Copilot CLI	Implemented	copilot plugin install (subdir spec)	Yes, machine-level rather than per project	Project-level only. Run archcore init --agent copilot (the plugin ships no MCP server here)	sessionStart, preToolUse, postToolUse

Production means the plugin is deployed and used day-to-day; bug fixes and new skills ship through the marketplace.

Implemented means every skill and agent works and all documented hooks fire. Some host-level edge cases still surface, listed below.

archcore plugin install acts on three of the four hosts and reports what it found on each. Cursor is the exception: it has no command-line plugin mechanism, so the CLI prints the UI instruction instead. On Codex CLI and GitHub Copilot the plugin lands in a machine-level store outside the repository, so one install serves every project on that machine. Install the plugin has the commands.

Copilot support is CLI only. VS Code agent mode has no self-serve plugin install, and cloud-agent sandboxes do not load plugin hooks.

Host-specific differences

Plugin manifest

Each host reads its own manifest, and the fields differ because each host discovers different parts of the package.

Host	Manifest file	Declares
Claude Code	.claude-plugin/plugin.json	mcpServers (convention-based for the rest)
Cursor	.cursor-plugin/plugin.json	skills, agents, hooks, rules
Codex CLI	.codex-plugin/plugin.json	skills, hooks, mcpServers, interface
GitHub Copilot CLI	.plugin/plugin.json	skills, agents, commands, hooks, and an empty mcpServers

Copilot’s empty mcpServers is deliberate. See GitHub Copilot CLI below.

MCP server registration

Host	Who registers MCP	Command
Claude Code	The plugin, via .claude.mcp.json	archcore mcp
Cursor	You, via ~/.cursor/mcp.json or .cursor/mcp.json	archcore mcp --project ${workspaceFolder}
Codex CLI	The plugin, via .codex.mcp.json	archcore mcp
GitHub Copilot CLI	You, via archcore init --agent copilot	archcore mcp --project <path>

Every host needs the Archcore CLI installed globally. Install it with the script on the CLI install guide.

Hook files

Host	Hook file	Write matcher	Path env var
Claude Code	hooks/hooks.json	Write|Edit	${CLAUDE_PLUGIN_ROOT}
Cursor	hooks/cursor.hooks.json	Write	${CURSOR_PLUGIN_ROOT}
Codex CLI	hooks/codex.hooks.json	Write|Edit|apply_patch	${PLUGIN_ROOT}, Codex’s host-neutral name
GitHub Copilot CLI	hooks/copilot.hooks.json	create|edit|str_replace_editor|apply_patch	$COPILOT_PLUGIN_ROOT, falling back to $PLUGIN_ROOT then $CLAUDE_PLUGIN_ROOT

All four hook files ship in the same plugin package, and the host selects the right one automatically.

Since v0.7.0 the hook scripts in bin/ carry only host glue. Every guard and advisory runs inside the CLI, through archcore hooks <host> <event>. See How the plugin works and the CLI hooks reference.

Cursor

Cursor exposes afterMCPExecution instead of a post-tool event. It fires after an MCP tool call succeeds, and the plugin runs the whole post-write pass there in one invocation. If the MCP call itself fails, the hook does not fire, and you see the MCP error directly.

Cursor also does not auto-register plugin-provided MCP, so you copy the docs/cursor.mcp.example.json template yourself. Keep the --project ${workspaceFolder} argument: without it, one registration reads a single project’s .archcore/ across every Cursor window.

Cursor is the only host that loads the plugin’s rules/ directory (archcore-context.mdc and archcore-files.mdc).

Codex CLI

One adapter covers both Codex surfaces, the CLI and the desktop app. They share one binary, one ~/.codex/config.toml, and one plugin install, so the agent id is codex-cli on both and no artifact distinguishes them.

Codex applies project wiring only after two separate consents. It loads a project’s .codex/ layer only for a project marked trust_level = "trusted", and it runs a command hook only after you review and trust it under /hooks. Writing the files grants neither, so wiring stays inert until you give both.

Codex CLI uses the same PostToolUse semantics as Claude Code, and adds Codex’s apply_patch tool to the PreToolUse matcher. Codex’s hooks feature gates Codex hooks. Enable it with codex --enable hooks, or add a [features] table to ~/.codex/config.toml:

[features]
hooks = true

Before Codex 0.129.0 the key is spelled codex_hooks = true. On Codex CLI 0.153.4, codex features list reports hooks as stable and enabled by default; check that feature on your installed version. Without it, hooks are inert, and skills, MCP, and agents still work.

The path env var is ${PLUGIN_ROOT}, Codex’s canonical host-neutral name. There is no ${CODEX_PLUGIN_ROOT} variable.

GitHub Copilot CLI

Copilot needs two steps, and both are required:

copilot plugin install archcore-ai/plugin:plugins/archcore
archcore init --agent copilot --project "$PWD"

Step 2 is not optional. Copilot launches a plugin’s MCP server in the plugin install directory with no project path (github/copilot-cli#4234), so a plugin-provided server would serve the plugin cache instead of your repository. The plugin therefore declares an empty mcpServers, and the project-level entry written by archcore init --agent copilot is the only source of document tools. Archcore CLI v0.6.7 and later refuses to serve from a plugin cache, so the failure mode is loud rather than silent.

A project that skips step 2 loads skills and hooks but has no document tools at all. The session-start hook detects the missing wiring and prints the command to run.

Copilot’s preToolUse event carries only a permission decision, so it cannot receive advisory context. The write guard runs there; the code-alignment injection does not. Copilot also reads .claude/settings.json, so a repository wired for both hosts can run the hooks twice. The verdict stays correct.

Command surfaces

Each host surfaces the four skills through its own convention:

• Claude Code, Cursor, and Codex CLI load skills directly from skills/<name>/SKILL.md.
• GitHub Copilot CLI additionally declares commands/, which holds one <name>.md wrapper per command.

The skill content is the same on every host. Only the entry point differs.

Agents

archcore-assistant and archcore-auditor ship in three formats:

• .md under agents/ for Claude Code and Cursor.
• .toml under agents/ for Codex CLI. The auditor uses sandbox_mode = "read-only"; the assistant uses sandbox_mode = "workspace-write".
• .agent.md under copilot-agents/ for GitHub Copilot CLI.

Tool whitelists are identical across formats. See Built-in agents.

Choosing a host

Use Claude Code if:

• You want the host with the deepest testing coverage.
• You’re already invested in the Claude Code CLI workflow.

Use Cursor if:

• You prefer a full editor over a terminal-first agent.
• You want afterMCPExecution semantics (a single post-MCP hook).

Use Codex CLI if:

• You want a terminal-first agent that registers MCP for you.
• You’re comfortable enabling Codex’s hooks feature to get full hook coverage.

Use GitHub Copilot CLI if:

• You’re already on Copilot and can run the one-time archcore init --agent copilot wiring step.

Other agents

The plugin does not run on an MCP-aware agent without a plugin runtime. Gemini CLI, OpenCode, Roo Code, and Cline use the CLI path instead, which gives them MCP access and agent integrations without plugin skills or guided flows. archcore plugin --agent <id> rejects those ids with an error naming the four hosts that ship a plugin.

Track planned host support in the plugin repository.

Next steps

• How the plugin works describes the hook lifecycle that differs per host.
• Install the plugin covers archcore plugin install and the marketplace command for each host.
• Plugin troubleshooting covers host-specific issues.