Harness compatibility

Current matrix, derived from the integration implementations themselves.

🟢 native · 🟡 adapted · 🟠 degraded · ⚪ roadmap · 🧪 experimental · — n/a

Project context: All harnesses read AGENTS.md natively via uze; @AGENTS.md bridge for Claude Code, native file for others.

Planned harnesses

⚪ roadmap — no integration yet; cells flip when it lands.

Invoking a plugin

flow:commit is model+user; workflow:review is user-only (never auto-invoked):

Notes per harness

• Claude Code — plugin delivery through a UZE-managed marketplace; skills-dir reference as fallback. Project context arrives through the CLAUDE.md bridge (@AGENTS.md).
• Codex — same marketplace model (~/.agents/skills shares its root with OpenCode); user-only skills carry agents/openai.yaml with implicit invocation disabled.
• OpenCode — V2 consumes no external plugin envelope: skills and agents are delivered natively, MCP through its global config, hooks through an owned plugin bridge. The runtime shim dispatches opencode to the legacy opencode2 binary cleanly.
• Antigravity — the Google-family v0 harness: the canonical plugin.json is a valid plugin manifest, so envelope-less packages install straight from the Store. Non-default invocation policies are adapted — no explicit-only mechanism exists; skills stay model-discoverable and slash-invocable.

The runtime PATH shim

An experimental mechanism that projects AGENTS.md into a harness without writing into the project — a real shim symlink in $UZE_HOME/shims that resolves the real harness binary without ever recursing into itself. Antigravity opts in too via agy setup; disable it by removing the symlink.