Vorn plugin

Teaches a coding agent what it can do when it runs inside Vorn, and installs the Vorn MCP server that gives it those abilities.

Without this, an agent in a Vorn session behaves like an agent in a bare terminal. With it, the agent knows it can drive a browser pane, drive an iOS simulator, start and steer sibling agents, and build and run workflows.

Claude Code

/plugin marketplace add vorn-run/plugin
/plugin install vorn

Copilot CLI

copilot plugin marketplace add vorn-run/plugin
copilot plugin install vorn@vorn

copilot plugin install vorn-run/plugin also works today, but installing straight from a repo is deprecated and will stop working.

Codex

codex plugin marketplace add vorn-run/plugin
codex plugin add vorn@vorn

Codex has no plugin install, and plugin add needs the <plugin>@<marketplace> form — a bare vorn is rejected.

Restart, or start a fresh session — bundled skills load at session start.

opencode reads skills natively. Add the MCP server, then point its skills.paths at a clone of this repo:

opencode mcp add vorn -- npx -y @vornrun/mcp@0.7.5
git clone https://github.com/vorn-run/plugin ~/.config/opencode/vorn

// ~/.config/opencode/opencode.jsonc
{
  "skills": { "paths": ["~/.config/opencode/vorn/skills"] }
}

The same SKILL.md files the other harnesses use — opencode discovers them through its own skill tool, so there is no plugin to install.

Gemini CLI

gemini extensions install https://github.com/vorn-run/plugin

The extension carries both the MCP server and the skills — Gemini has no skills system, so GEMINI.md includes all four skill files directly rather than loading them on demand.

Gemini suppresses MCP servers, including user-level ones, in a folder it does not trust. If the server shows as Disabled, trust the folder or pass --skip-trust.

On every harness with a skills system, these load on demand — about 324 tokens always-on, and roughly 1k more only when a skill actually fires. Gemini has no skills system, so its extension includes all four up front instead.

Agents defer MCP tool descriptions — a tool's name enters context, its documentation usually does not. So browser_interact appearing in a tool list does not tell an agent that refs come from read_page, that refs die on navigation, or that console capture starts when the pane opens. The skills carry that; the tool list carries the names.

Skill bodies are also re-injected after compaction, where prompt text is summarised away.

.mcp.json asks for an exact @vornrun/mcp version rather than @latest.

@latest reads whichever registry the machine is pointed at, and a mirror that has stopped syncing still answers -- it serves what it last fetched, under whatever tag it last saw. Nothing errors in that case: the server starts, the tools load, and the only symptom is a tool that should exist and does not. A pinned version turns silence into a failure you can read.

Bump it deliberately when the server gains something the skills rely on.

• The Vorn app running (the MCP server talks to it over a local socket)
• Browser tools additionally need an interactive session started by Vorn — headless runs have no pane

.claude-plugin/plugin.json   Claude Code manifest
.codex-plugin/plugin.json    Codex manifest
plugin.json                  Copilot CLI manifest
.mcp.json                    MCP server definition
skills/<name>/SKILL.md       shared by every harness

Three manifests, one set of skills. Claude, Copilot and Codex all read skills/<name>/SKILL.md, so the content is written once.

MIT