Use cursor-agent as the engine.
Cursor's headless agent, with the diagram canvas and the approval gate wrapped around it.
Choosing Cursor CLI makes Lucid Train spawn `cursor-agent acp` and speak ACP, a JSON-RPC agent protocol, over stdio. This is Cursor's command line agent rather than the Cursor editor, so it runs headless and its output is rendered by Lucid Train's own diff and approval UI. Cursor CLI drives coding tabs only. Design mode has no Cursor provider, so a Design tab stays on Claude Code or Codex regardless of what your coding tabs are set to.
ACP, and why the protocol matters here
`cursor-agent acp` speaks the Agent Client Protocol, a JSON-RPC dialect designed for exactly this: an editor or harness driving an agent it did not write. Because it is a real protocol rather than screen-scraped terminal output, tool calls, diffs and permission requests arrive as structured events and can be rendered natively instead of being parsed back out of text.
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.
This is the CLI, not the editor
Worth stating plainly because the names collide. Cursor the editor is a VS Code fork with its own interface. cursor-agent is a separate command line program, and that is what runs here. Nothing about this opens, replaces or integrates with the Cursor editor, and you can run both without either noticing.
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.
What runs on top
The same wrapper every engine gets: risk-tiered command approval, reviewable diffs before anything lands, the diagram canvas whose output can be handed over as a specification, and Lucid Train registered as an MCP server so its diagram tools are available inside the session.
What the engine picker needs
| Value | |
|---|---|
| Binary on PATH | cursor-agent |
| Install | curl https://cursor.com/install -fsS | bash |
| Sign in | cursor-agent login |
| Transport | cursor-agent acp, ACP over stdio |
| Drives Design mode | No |
| API key needed by Lucid Train | None |
Questions
Related
- 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.
- Run Lucid Train on Claude CodeThe same binary you already run in a terminal, driven from a window that also has your diagrams, your dependency audit and your dashboards in it.
Last updated