Command Code vs OpenCode: MCP, Mods and Plugins

Command Code vs OpenCode gets confusing when you start adding extensions. Both support MCP servers and Agent Skills, but their mods and plugins use different APIs and install paths.

MCP connects the agent to an outside service. A Skill gives it reusable instructions. A mod or plugin changes what the agent itself can do.

Command Code is the command-code CLI, launched with cmd (or cmdc on native Windows). OpenCode is the open-source coding agent from Anomaly, with a terminal UI, desktop app and IDE extension. This comparison follows OpenCode v2 because its MCP configuration differs from v1.

MCP is the shared layer

MCP, the Model Context Protocol, connects either agent to an external service such as a tracker, database, documentation search or browser. You add a local process or remote endpoint; once connected, you can ask for the task without memorizing each tool name.

On Command Code the command is cmd mcp. Remote servers take --transport http. Local ones are the default, and a double dash splits the name from the process.

Scope defaults to local, which stores a private configuration for the project under your home directory. --scope project writes .mcp.json so the team can commit it. --scope user writes ~/.commandcode/mcp.json for every project. The same name in a closer scope wins: local over project over user.

Inside a session, /mcp shows status, tool counts, and OAuth. Tool names look like mcp__notion__search_page.

On OpenCode v2 the command is opencode mcp add. A URL makes a remote server. --global makes it available in every project. Otherwise the command writes the project config.

Remote servers use OAuth by default. If the list says the server needs authentication, open OpenCode and use /mcps. In the file, servers sit under mcp.servers, not as bare keys directly under mcp. That bare-key shape is the v1 docs. Use the configuration format for your installed version.

MCP tools also use context, so connect only the servers you need. Command Code can import an OpenCode setup with /import opencode, but this creates a copy, not a live sync. Each agent keeps its own configuration after import.

Mods and plugins are the code layer

A Command Code mod is a TypeScript factory. Command Code loads it with jiti, so there is no compile step. The factory receives a ModApi. It can add tools, slash commands, feed renderers, model providers and a footer status segment.

Hooks are allowed to change behavior: block a tool, rewrite input, append to the system prompt. cmd.on(...) only watches. It cannot stop a tool. Mods are not sandboxed. Install only code you trust. Project mods load after you trust the workspace; user-scope mods load across projects.

You install one with cmd mods add, from npm, GitHub shorthand, or a local directory. The source is stored in settings. The files land in a registry folder. Startup will not run npm or git by itself. If a configured package is missing, cmd mods update is the fix. /reload restarts the process and loads every mod again.

An OpenCode plugin is also TypeScript or JavaScript, and it can add tools, hooks, commands, and agents. The v2 plugins page installs a package with opencode plugin add, including a pinned version, a scoped name, or a git spec, or you list it in the plugins array of opencode.json.

For a local plugin, drop a .ts or .js file in .opencode/plugins/, or in ~/.config/opencode/plugins/, and it is discovered. A plugins/ folder sitting next to a project opencode.json is not discovered. Move it under .opencode/ or name the path.

Watched files reload on their own. Package installs that are missing at startup are fetched in the background.

OpenCode keeps policy-enforcement plugins enabled, even if a repository tries to remove them. Its CLI-only plugins can sit in cli.json and run locally when the CLI connects to a remote server. In Command Code, a mod can add a footer status with cmd.ui.setStatus, which is useful for a meter or small HUD.

We maintain separate token meters for Command Code and OpenCode. They target different agent APIs, so their install steps are not interchangeable.

The opencode-token-metrics README documents a tui.json configuration. OpenCode v2 now documents CLI-only plugins in cli.json, so treat this package as version-specific and verify compatibility before following its setup instructions.

Agent Skills work differently

A skill is a folder with a SKILL.md file. It is instructions, loaded when the task matches, not code that runs inside the host. Both agents follow that idea, and both also look in .agents/skills/ and ~/.agents/skills/, which is why a playbook sometimes appears in both without a port.

Command Code stores its own copies in .commandcode/skills/ and ~/.commandcode/skills/. cmd skills add owner/repo installs from GitHub. You invoke one as /skill-name, or /skill:name if a built-in command already took the name.

OpenCode v2 looks in .opencode/skills/ and ~/.config/opencode/skills/, plus the Claude and agents compatibility paths. The agent loads the file through the skill tool instead of pasting every skill into every prompt.

A mod or a plugin that “manages skills” is still code. skill-hub-mod on Command Code is a mod that shells out to the skills.sh CLI. It is not the same thing as a SKILL.md file, and it is not OpenCode’s skill loader.

Can you use the same setup in both?

A shared Skill folder can save you from maintaining the same instructions twice. An MCP server can also serve both agents, although each needs its own connection settings. Mods and plugins need separate implementations because they use different agent APIs.

• SourceCommand Code MCP docs

• SourceCommand Code mods docs

• SourceCommand Code skills docs

• SourceCommand Code

• SourceOpenCode v2 MCP docs

• SourceOpenCode v2 plugins docs

• SourceOpenCode v2 skills docs

• SourceOpenCode v1 MCP docs

• SourceOpenCode docs intro

• Sourcecommandcode-token-metrics

• Sourceopencode-token-metrics on npm

• Sourceopencode-token-metrics on GitHub