LazyCodex ships almost none of the agent behavior it advertises. The engine, OmO, sits under src/ as a git submodule. What the repository itself holds is a distribution layer, a Next.js site, and two CI workflows. That split is the interesting part. Someone looked at a working agent harness and concluded the remaining hard problem was not the agents. It was getting them installed, verified, and cleanly removed on a machine nobody on the project has ever seen.
Installation is treated as a first-class feature
The primary path is one line, and the README is insistent about it: npx lazycodex-ai install, no global install, no npm i -g. That command expands to npx --yes --package oh-my-openagent omo install --platform=codex. If you want the version that never stops to ask, --no-tui --codex-autonomous gives you an unattended setup. Note where that flag lives. The newer marketplace route, adding the repo as a marketplace inside Codex and installing omo@sisyphuslabs, never touches Codex permission settings. Autonomous mode stays something you type on purpose.
The marketplace path also documents its own awkwardness, which is rarer than it should be. Hooks do not run until you approve them in Codex's startup review. The first approved session prints a notice that bootstrap is running in the background and that you should restart when it completes, because a worker is still writing config blocks, agent roles, bin links, and a pinned sg binary for the ast_grep MCP. After an upgrade, that same startup review shows the hooks as Modified, which the README calls expected rather than leaving you to wonder what got tampered with.
Then there is npx lazycodex-ai doctor, which prints a health report across plugin cache, hooks, MCP servers, agents, and config state. Uninstall is equally specific: plugin cache, bin links, agent roles, and the managed sections of ~/.codex/config.toml. A tool that names the exact regions of your dotfiles it claims ownership of is a tool you can let near them.
Three commands, then a drawer of skills
The command surface stays small. $ulw-plan writes a plan to plans/<slug>.md and never writes product code, so planning cannot quietly turn into a half-finished implementation. $start-work executes that plan until every checkbox is done and prints ORCHESTRATION COMPLETE. $ulw-loop runs a self-referential loop until an Oracle verification passes, capped at 500 iterations in ultrawork mode and 100 in normal mode. Those caps are the honest detail. Anyone who has watched an agent loop knows the failure mode is not stopping too early.
Below the commands sits a skill layer you reach by typing $ in the Codex composer. $init-deep scores complex directories and writes hierarchical AGENTS.md files near the code that needs them, so future agents get landmarks before they start editing. Others cover narrower ground: LSP for diagnostics, definitions, references and renames, AST-grep for structural search and rewrite, review-work for post-implementation review, remove-ai-slops for behavior-preserving cleanup of code that reads like it was generated.
Sub-agent roles get installed into ~/.codex/agents/ as explorer, librarian, plan, momus, metis, and codex-ultrawork-reviewer. You pick one by passing agent_type to Codex's own spawn_agent tool. The installer exposes that parameter on multi_agent_v2 sessions because Codex hides it by default, and if your build has no such parameter, the skills fall back to describing the role inside the message.
Routing is about quota, not novelty
A LazyCodex run will show different models mid-session: gpt-5.4-mini on a small edit, a high-reasoning GPT model on hard logic, a Codex-tuned model on agentic coding paths. The source defines task categories and fallback chains that make this choice, and the README points at openai-categories.ts and model-requirements.ts rather than asking you to take its word.
The stated reason is quota discipline. Parallel agents burning a frontier model on routine steps is how you run out of budget before you run out of work. Routing a quick category to a cheaper model is not a performance claim, it is an accounting one.
That framing runs through the whole project. The README's own standard is that lazycodex should be judged by the features it actually installs, which is a reasonable bar to hold any harness to, including this one.
GitHub: https://github.com/code-yeongyu/lazycodex
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
