Start with read-only MCP
If your team needs inspection first, start with the protocol boundary and confirm what agents can read before you talk about packages or skills.
One truthful compatibility matrix for modern coding-agent teams.
CortexPilot already fits real Codex and Claude Code workflows, and it can still sit next to adjacent tools such as OpenClaw without inventing fake plugin claims. This page exists so a team can answer one practical question fast: what works today, what should we open first, and what should we not overclaim?
The shortest honest story is: Command Tower, Workflow Cases, Proof & Replay, read-only MCP, repo-owned skills, and builder packages. The current public boundary is still not a hosted operator product and still not a write-capable MCP story.
The shortest compatibility matrix
| Surface | Codex | Claude Code | OpenClaw | Truthful boundary |
|---|---|---|---|---|
| Command Tower + Workflow Cases | Primary workflow fit | Primary workflow fit | Adjacent review surface only | Use these as the shared operating record. Do not turn them into hosted-team-account claims. |
| Proof & Replay | Yes | Yes | Yes, if explicitly mapped through the same review loop | Proof and compare are real today. They do not imply a broader plugin marketplace. |
| Read-only MCP | Yes | Yes | Yes, as a read-oriented protocol layer | The shipped public MCP contract is read-only. |
| Repo-owned skills | Direct fit | Direct fit | Adaptation layer | Skills are repo-owned playbooks, not official plugin listings. |
| Builder packages | Thin client + contract + shared substrate | Thin client + contract + shared substrate | Usable when explicitly mapped | Useful package entrypoints today, but not a full SDK platform. |
| Official plugin/store path | No current CortexPilot claim | No current CortexPilot claim | No current CortexPilot claim | Do not say CortexPilot already ships an official plugin for any of these ecosystems. |
Choose your first move
Start with repo-owned skills
If the main problem is repeatable agent behavior, start with the skill pack and reuse the repo's own playbooks instead of inventing plugin language.
Start with builder entrypoints
If you need a thin client, contract-facing types, or shared frontend substrate, move down the builder ladder after the protocol boundary is clear.
Start with use cases
If you need to prove the story to a team first, use the public proof-first loop and share-ready Workflow Case surfaces before deeper adoption.
Good framing vs bad framing
"CortexPilot works with Codex and Claude Code workflows through Workflow Cases, Proof & Replay, read-only MCP, repo-owned skills, and builder entrypoints."
"CortexPilot already ships the official Codex, Claude Code, or OpenClaw plugin."
"OpenClaw stays adjacent and can use the same review/proof layer when an explicit mapping is shipped and tested."
"OpenClaw is a first-class native surface inside CortexPilot today."
FAQ
Is this an official plugin page?
No. This is a truthful compatibility and adoption page for repo-owned surfaces that already exist today. Plugin wording stays narrow and ecosystem-specific instead of becoming the default umbrella term.
Does MCP support writes?
No. The public MCP contract remains read-only. Guarded queue and operator mutation groundwork does not change that public promise.
Should a builder start with packages or protocol?
Usually protocol first, then packages. Start with MCP or API if you need the truth boundary, then move to builder packages once the fit is clear.
Where does OpenClaw fit?
OpenClaw belongs in the adjacent coding-agent layer unless a real mapped bundle or native path is explicitly shipped and tested.