Reference

Codex Runtime

One skills tree, two runtimes.

EvalGlass packages for Codex as a second runtime from the same repository and the same canonical skills/ tree — no forked guidance. Only thin per-runtime manifests differ. The vendored runtime a host ends up with is identical whichever runtime installed it, and keeps working after the plugin is removed (ADR 0023).

The packaging principle is single-source: skill frontmatter is runtime-neutral, skill bodies carry no runtime-specific packaging internals, and any skill that names a Claude-only ${CLAUDE_PLUGIN_ROOT} launcher also offers the portable direct CLI — so a Codex session has a working invocation. A deterministic sync keeps the synced Codex copy byte-identical to the canonical source.

What's shared, what's thin

Surface	Claude Code	Codex
Skills	`./skills/` — the same canonical tree, no fork
Trigger / routing manifest	`.claude-plugin/plugin.json`	`.codex-plugin/plugin.json` (adds the `interface{}` block Codex renders)
Runtime entry doc	`SessionStart` hook (display-only)	root `AGENTS.md` (display/routing-only; defers to `CLAUDE.md`)
Integration-time CLI	bundled launcher `${CLAUDE_PLUGIN_ROOT}/bin/evalglass-launch`	portable `python -m evalglass.installer … --root .`
Host evaluation	`PYTHONPATH=evals python -m _evalglass.harness.cli …` — identical across runtimes

One identity, one version line The name, version, and license in .codex-plugin/plugin.json are byte-identical to the Claude manifest — one repo, one identity, one version line (now 0.1.0). The interface prose is in honesty-audit scope, like every other plugin surface.

Skills-only on Codex

A canonical Codex plugin ships skills/ plus the manifest; the sync deliberately excludes src/, bin/, hooks/, commands/, and the dev gates. So a Codex install has no bundled launcher — its integration-time path is the always-portable direct CLI, which every skill already documents alongside the Claude-only launcher. Host evaluation on either runtime runs the host's vendored _evalglass.

Runtime independence — across runtimes

The deletion-invariant holds across runtimes: remove the plugin (on either runtime) and every host verdict is byte-identical, because host evaluation never depends on the plugin. The vendored runtime is the same whichever runtime installed it. How vendoring works →

A public Codex listing is not yet published The repo ships the deterministic sync script, a drift self-check, the acceptance-probe runbook, and the cross-runtime docs. The outward actions — the real marketplace submission, the cross-repo sync PR, and a live acceptance-probe transcript — are maintainer steps, reported as not exercised, never as passing. Until then, install on Codex with the portable direct CLI.

Next steps

Reference

CLI Reference

The portable invocations both runtimes share.

Vendoring

EvalGlass Skill

What is vendored — and what never is.

Reference

ADR Index

ADR 0023 records this decision.