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):

Reading the columns

Notes per harness

Each name links to that harness's own site; what follows is how uze delivers to it.

• Claude Code — plugin delivery through a UZE-managed marketplace; a skills-directory reference is the fallback. Project context arrives through the CLAUDE.md bridge (@AGENTS.md) — the only bridge uze maintains. Hooks merge into its own user-scope hook configuration.
• Codex — the same marketplace model; its skills root (~/.agents/skills) is shared with OpenCode, which uze accounts for when resolving names. User-only skills carry agents/openai.yaml with implicit invocation disabled. Hooks merge into Codex's own hooks.json command form.
• OpenCode — consumes no external plugin envelope: skills and agents are delivered natively, MCP through its global config, and hooks through an owned, regenerable plugin bridge, since no declarative hook surface exists. A Skill is invoked as a mention (@flow:commit), not a slash command — slash: false withholds one from the / catalog but a mention still expands it, which is why a user: false policy is reported adapted rather than native. Its binary is detected as opencode, with the legacy opencode2 alias still resolved.
• Antigravity — the Google-family v0 harness (ADR-027): 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, so skills stay model-discoverable and slash-invocable. It carries the widest hook effect set of the four.

Profiles

Alongside packages, uze models user intent about how a harness behaves, and each integration translates it into that harness's own settings file. Three axes, deliberately small:

Edit them on the Profiles screen of the management TUI (Ctrl+O). Apply makes the selected profile active and writes it into every checked harness; being active and being in effect are different things, so the drawer says which — a profile edited since it was applied, or a settings file changed by hand, reads Active, not in effect.

Preview (v, or the drawer's Preview button) answers before anything is written: one row per harness with a word for each axis — as asked, adapted (set another way), partial (not fully honoured) or n/a (no such setting) — and whether applying would change anything there. A harness with something to write opens by itself onto its own file: each key with what applying adds, changes or removes, and the reason behind any partial or n/a. For example:

• Claude Code's sandbox limits writes to the working directory, which is workspace-write exactly; read-only cannot be delivered from user-scope settings and is reported degraded. On Linux and WSL2 its sandbox needs bubblewrap and socat, and the preview says when one is missing — without them Claude runs every command unsandboxed. Auto mode does not run on Haiku, so auto with the fast model accepts edits instead and says why.
• A default model is the key being absent, never the word default, which Claude Code cannot resolve. Any model that does resolve is left where it is — nothing in the file says whether you wrote it or an earlier profile did, so uze never assumes it was its own.
• Codex needs an exact model id and publishes no tier-alias catalogue, so anything but default is reported unsupported rather than guessed into a model that may not exist. It no longer has a policy that asks before every command, so manual is its most careful one, reported degraded.
• OpenCode has no single autonomy key — permissions are independent per-category values — so autonomy is always adapted, decomposed across several keys.
• Antigravity's model is a label from the signed-in account's own catalogue, so fast and capable are unsupported; its other mappings are adapted, never native.

Every value uze writes is checked against the shipped harness binaries, not only their docs.

A preference is never carried by guessing a key. Where a harness cannot express an axis, uze says so and writes nothing: overwriting a setting you made yourself is worse than not carrying the intent.

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, a boundary held by its own test. Disable it by removing the symlink.