Codex Engine

Codex is Jaunt's only generation engine. Model-backed implementation, test, contract, skill, and project-overview work drives the OpenAI Codex CLI (codex exec). Jaunt keeps discovery, dependency ordering, freshness, validation, repair retries, and artifact transactions for itself.

Writing a file does not automatically mean calling Codex. TypeScript sync, reviewed design --apply, compatible migrate --language ts --apply, check, and deterministic re-stamps use the worker and local toolchain only. Fresh build and test targets skip generation too.

Prerequisites

Codex is an external CLI, so install and authenticate it once before you run Jaunt:

# Install the Codex CLI (see the OpenAI Codex docs for your platform), then:
codex login

Jaunt shells out to whatever codex is on your PATH. Authentication belongs entirely to Codex — codex login, or the CODEX_API_KEY env var. Jaunt does not read llm.api_key_env for generation. The [codex] keys that pick the model, reasoning effort, and sandbox policy live in the configuration reference.

How a generation call works

For each module that needs model-backed generation:

1. Jaunt renders the target prompt from your contract, per-spec extras, project context, and target templates, then seeds builtin and project skills into the workspace at .agents/skills/ for Codex to find.
2. It spawns one codex exec --json subprocess and passes the prompt on stdin.
3. Codex edits inside the configured sandbox; Jaunt reads the JSONL event stream for the final result.
4. Python validates the proposed module with AST and type checks. TypeScript asks Codex for reserved internal bindings, composes the deterministic exports, and checks the complete candidate in the owning compiler overlay, including affected project references. Either target can run bounded repair retries before an atomic write.

Each call is its own subprocess. There are no shared credentials and no process-wide locks, so generation is task-local and parallel-safe by construction — Jaunt just runs several codex exec processes at once.

Freshness

The Codex runtime is part of what Jaunt fingerprints for freshness: switch the model, sandbox, reasoning effort, or target prompt templates, and affected modules become stale without --force. A fingerprint-only change can be validated and re-stamped without asking the implementation model to rewrite the body. The full list is in Change Detection.

Test generation

Generated pytest and Vitest modules have to satisfy the literal test specs you wrote. Jaunt tests through the public module contract, not generated internals. Spell out every behavior you want covered rather than trusting the engine to guess at a broad, unstated matrix: the model writes what you specify, not what you meant.

See also: Configuration and Limitations.