Use the OpenAI Codex CLI as the engine.
JSON-RPC to a local app-server, and the only engine besides Claude Code that can also drive the design canvas.
Selecting Codex makes Lucid Train spawn `codex app-server` and speak JSON-RPC to it over stdio. It is the Codex CLI you installed, authenticated the way you authenticated it, running locally. Codex is also one of the two providers that can power Design mode, where it runs `codex exec --json` once per completion with the sandbox set to read-only and approvals never, so a design turn cannot write to your repository.
app-server, not one shot per turn
`codex app-server` is a long-running process that speaks JSON-RPC, so the harness opens it once and keeps a conversation on it. That is what makes session resume work rather than re-sending the whole history every turn, and it is the same reason the Claude Code integration uses a persistent process.
Whose credential is used
On this route Lucid Train never sees the credential. It looks for the binary on PATH, spawns it as a child process, and speaks its protocol. Authentication is whatever that CLI already did when you signed into it, so the entitlement stays between you and the vendor and nothing is proxied, replayed or re-signed.
Design mode runs it differently
Design is the one place Codex is invoked per completion rather than kept alive: `codex exec --json`, one process per generation, sandbox read-only, approvals never. That is deliberate. A design turn should be able to read the project for context and should never be able to edit it, and the sandbox flag enforces that at the process level rather than by asking the model nicely.
The two engine lists
One thing worth separating, because the two lists genuinely differ: the engine that runs a coding tab and the provider that powers Design mode are chosen independently. Coding tabs accept Claude Code, Codex, Cursor CLI and OpenCode. Design mode accepts Claude Code and Codex only. Picking Cursor for your coding tab does not move Design onto Cursor, because there is no Cursor provider behind that canvas.
Where it sits against the bundled engine
The bundled Lucid engine talks to providers directly, so it can point at local Ollama, at OpenRouter, or at any OpenAI-compatible endpoint with your own key. The Codex engine cannot do that, because it is Codex. Choose by what you already pay for: an existing Codex CLI login costs nothing extra here, and a local model costs nothing at all.
What the engine picker needs
| Value | |
|---|---|
| Binary on PATH | codex |
| Install | npm i -g @openai/codex |
| Sign in | codex login |
| Transport | codex app-server, JSON-RPC over stdio |
| Drives Design mode | Yes, via codex exec --json |
| API key needed by Lucid Train | None |
Questions
Related
- Run Lucid Train on the Cursor CLICursor's headless agent, with the diagram canvas and the approval gate wrapped around it.
- Run Lucid Train on OpenCodeThe open-source option, and the only engine that talks HTTP rather than stdio.
- Run Lucid Train on OpenRouterOne key, many models, and the only route here that lets you split Plan, Edit and Vision across different providers.
- Run Lucid Train on a Claude or ChatGPT SubscriptionNeither route asks you for an API key. One of them is a supported integration and one of them is interop; the difference matters.
Last updated