INTEGRATIONS

One contract, materialized differently per host

Yana doesn't run a second copy of itself inside each coding agent. It generates adapters from one canonical core/ layer — but the host decides how strongly that adapter can actually enforce anything. This page states each difference plainly, not as a uniform "works everywhere" claim.

Claude Code

Strict parity

The harness Yana's own hooks were built and battle-tested on first.

Mechanism

Native PreToolUse / PostToolUse / Stop hooks in .claude/settings.json, calling core/hooks/*.sh directly.

Enforcement

Deterministic shell guards run before the tool call ever executes — this is the reference implementation the others are checked against.

Codex

Strict parity

Machine-verified against Claude Code — the only other harness held to that bar today.

Mechanism

.codex/hooks.json + .codex/agents/*.toml, generated from the same core/ source — never hand-maintained separately.

Enforcement

check_engine_parity.py fails the build if Codex is missing any shared instruction, agent, skill, command, or active hook.

Capability	Claude Code	Codex
Instructions	AGENTS.md	AGENTS.md
Agents	.claude/agents/*.md	.codex/agents/*.toml
Hooks	.claude/settings.json	.codex/hooks.json

What "parity" means here: the hook files are present and synced — .codex/hooks.json is not hand-maintained, and the build fails if it drifts from Claude Code's set. Whether Codex's own runtime enforces a block on every one of those hooks the same way Claude Code's does has not been independently re-verified as thoroughly as Cursor's beforeShellExecution path — README.md's own pitch is deliberately more cautious here ("hard-blocking on Claude Code and Cursor, advisory guidance on Codex and Antigravity"). Treat Codex's enforcement strength as real but less independently confirmed than Cursor's until that's checked directly.

Cursor

Native hook, not strict-parity

Real deterministic enforcement — just not yet held to the same machine-verified parity bar as Claude Code and Codex.

Mechanism

Cursor's own beforeShellExecution hook calls a thin translator that forwards straight to guard-destructive.sh — the exact same guard Claude Code uses, not a reimplementation.

Enforcement

Cursor's own failClosed: true is the backstop: if the translator crashes or times out, Cursor blocks the action regardless.

Honest gap: agents, skills, and commands aren't machine-verified in sync for Cursor the way they are for Codex — only the destructive-command guard is confirmed wired.

Antigravity

Prompt-level, not a hook

The clearest example of "enforcement strength varies by host" on this list.

Mechanism

A workspace rule (.agent/rules/yana-ai.md) or AGENTS.md that instructs the model: "NEVER execute rm -rf, git push --force..."

Enforcement

This is a system-prompt instruction the model is asked to follow — not a deterministic hook that blocks the call before it runs.

Why we say this plainly: a prompt can be followed correctly almost all the time and still be a fundamentally different guarantee than a hook that runs outside the model's own reasoning. Governance's own principle — don't ask an LLM whether a command is dangerous inside the authority path — doesn't fully apply here yet, and the site won't pretend otherwise.

Discord

No tool capabilities

A remote chat adapter with the narrowest surface on purpose.

Authenticated channel/user allowlists, in-process Rust TurnEngine, plain chat only. No host or tool capabilities are exposed remotely — Discord is deliberately not a remote shell into Yana. An empty allowlist denies everyone; an adapter failure never grants access by default.

MCP

Experimental / opt-in

Feature-gated, and deliberately unable to grant itself anything.

A stdio server over canonical, governed capability/workspace services — opt-in, off by default. Read and governed request surfaces are available; approval-only workspace operations cannot be approved over MCP at all. The transport cannot manufacture human authority, by design.