Harness compatibility
Package present does not mean behavior proven.
Use this matrix to choose an evaluation path. It describes repository surfaces, not equivalent outcomes, and it keeps Cursor and Gemini metadata distinct from native package support.
Prerequisites
Identify the exact harness and client version you plan to evaluate. Clone a reviewed revision, use a disposable project or destination, and decide which single outcome you will test. Record commands, loaded files, permissions, and rollback steps before comparing results across clients.
What exists today
| Harness | Repository surface | What it supports | Evidence boundary |
|---|---|---|---|
| Codex | Curated native plugin | Focused workflow skills and optional agent sync | Public outcome fixture still pending |
| Claude Code | Marketplace and plugin manifests | Client-managed plugin loading from the repository | Confirm schema, scope, dependencies, and loaded surface locally |
| Cursor | Generic repository and workspace files | Manual project context and selected local files | No dedicated native package or parity fixture published |
| Gemini | gemini-extension.json metadata | Repository context entry pointing to CLAUDE.md | Repository context is current; client loading still needs evaluation |
A fair comparison method
- Choose one fixtureUse the same bounded input, expected files, forbidden actions, and acceptance checks in each harness.
- Record the environmentCapture client version, model, plugin revision, permissions, and any manually copied context files.
- Run from clean stateUse new destinations and avoid personal memory, existing rules, or credentials that would make results incomparable.
- Compare evidenceEvaluate artifacts, checks, refusals, and rollback behavior—not prose style or an unrepeatable demo.
Cursor evaluation path
No dedicated Cursor package is currently represented as equivalent to the Codex plugin. Start with a clone and the smallest relevant files: the starter-kit README, selected agent role documents, and only the skills required for your fixture. Keep project rules explicit and inspect every proposed command. The generic installer can preview separate workspace-<agent> directories, but Cursor loading behavior remains a client configuration decision.
Gemini evaluation path
The root gemini-extension.json points to CLAUDE.md. Treat that context as an evaluation input rather than a runtime guarantee. Confirm that your Gemini client recognizes the file, what context it loads, and whether its permission prompts match the fixture. Do not infer support for generic installer destinations from the metadata alone.
Limitations
Model choice, context-window policy, tool permissions, plugin caching, and client updates can change the result even when the repository revision is fixed. This matrix does not claim equivalent feature coverage or output quality. A second harness should not move beyond pending status until it passes the same independently reproducible fixture.
Rollback and uninstall
For native plugins, use that client's scoped uninstall controls. For manually added project context, remove only files or settings introduced for the evaluation. For generic workspaces, use the installer preview record to identify new directories. Preserve evidence and configuration snapshots until the comparison is complete; never remove an entire user configuration directory as a shortcut.