Configuration
Install flags, the Codex platform target, zero-config defaults, and where provider and model setup lives in OmO.
LazyCodex keeps configuration minimal. The only knobs LazyCodex exposes directly are the install flags; everything past that — providers, models, routing, hooks — is configured in the underlying OmO engine.
Zero config by default
LazyCodex ships sensible defaults and works immediately after install. You only reach for configuration when a default is not right for your repo. There is no separate config file to create up front — run the installer and start working.
npx lazycodex-ai installNo global install. Always invoke via npx. This is shorthand for npx --yes --package oh-my-openagent omo install --platform=codex.
This is the "Codex Light setup": the installer wires the Codex marketplace plugin as
omo@sisyphuslabs, while the publiclazycodex-aipackage stays the alias/entrypoint you invoke.
The Codex platform target
LazyCodex always targets Codex. The --platform=codex argument is baked into the install path of the lazycodex-ai bin, so the harness is wired for the OpenAI Codex CLI rather than any other platform. You do not pass --platform yourself.
Prerequisites
- Bun
- The OpenAI Codex CLI
Install flags
The default installer is interactive (TUI). It detects subscriptions, helps pick models, and walks provider auth.
npx lazycodex-ai installIt is strongly recommended to let an LLM agent run the install and walk the setup — it handles subscription detection, model selection, and provider auth automatically.
For a fully autonomous, no-prompt setup, add both flags:
npx lazycodex-ai install --no-tui --codex-autonomous--no-tui --codex-autonomous are passed together for a fully autonomous, no-prompt setup. The lazycodex-ai bin does not interpret them — any flags after install are forwarded verbatim to omo install, which assigns their meaning.
Provider and model setup
Provider and model configuration is owned by OmO, not LazyCodex. During install, OmO asks which model subscriptions you have and routes each task category accordingly — this is the multi-model routing layer.
- The installer wires up provider auth for you. Letting an agent run it is the recommended path.
- Provider keys are read from your environment. Treat every
*_API_KEYand OAuth credential as a secret — never log or commit them. - Beyond install, deeper provider/model tuning follows OmO conventions. See the OmO documentation for its provider environment variables and model resolution rules.
Do not invent provider keys. Use the keys your chosen providers document, supplied through your environment, and let the installer resolve routing.