All help topics

How-to · When something breaks

Fix an engine Turret cannot find

Read why an engine's card is disabled on the New Session screen, and get it working.

An engine's card is greyed out on the New Session screen, and you want it working.

1. Open the sidebar's Vendors row and press the engine's own chip. The reason names itself only there and in the New Session card's tooltip, never as text printed on the card. Set up an engine shows the same cards for all four engines.
2. Press the card's blue button. Install Claude Code or Install Codex downloads the vendor's own installer into your own account, with no administrator password, and shows each step. Sign in to Claude Code or Sign in to Codex opens a sheet showing the CLI's own sign-in. Finish in your browser, and type into the box under the sheet's output whatever the CLI asks. Fix… appears when a copy is installed and does not start. Gemini and DeepSeek take their API key in a field on the card, and Turret checks it with the vendor before it saves it.
3. Press Check again once done.

The Fix… sheet lists each copy Turret found and marks the copy in use. It offers a single action. That action uses a copy that works, installs a fresh copy, or switches an npm copy to the vendor's installer. An old copy stays where it is.

The sheet's Choose executable… link is for a CLI installed somewhere Turret's own PATH misses. An app launched from outside a terminal often inherits a shorter PATH than a shell does.

Gemini and DeepSeek's binary ships inside Turret itself, rather than something you install — the same binary answers both engines. A development build never staged with that binary reports both as not found regardless of what else is set up.

TURRET_CODEX_BINARY points Turret at a Codex binary outside PATH without a picker in the app. See Environment variables for it — it is an override for a build with no other way to find the binary, not an ordinary fix.

See Engines and their models for the full set of readiness reasons.