The repository packages OmO for Codex
LazyCodex is a distribution layer around code-yeongyu/oh-my-openagent, called OmO in the documentation. It installs OmO's planning, execution, memory, routing, and review behavior into Codex. The headline commands have distinct jobs: $ulw-plan writes a plan without product code, $start-work runs that plan, and $ulw-loop keeps working until its verification rules accept completion.
The package adds skills for project instructions, language-server work, structural search, interface design, code cleanup, and review. $init-deep writes hierarchical AGENTS.md files. Six agent roles cover exploration, research, planning, and review. The house style either fits or turns each hook into another policy to learn.
One npx command installs hooks, agents, MCP tools, and config
The main route is npx lazycodex-ai install, with no global package required. It invokes an OmO install for Codex. doctor checks the cache, hooks, MCP servers, agents, and configuration; uninstall removes managed entries, links, roles, and config sections. This changes the Codex home rather than one project.
The Codex marketplace path is labeled experimental. After installation, Codex asks the user to approve OmO hooks. The first approved session starts a background bootstrap that finishes config blocks, roles, links, and a pinned sg binary for the AST-grep MCP, then asks for a restart. Each marketplace upgrade marks hooks as modified and requires another review. The npx autonomous flag is separate and explicitly changes Codex permission settings.
What happened when we ran it
Our run used commit 10f9558 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and Node 22. Installation succeeded in 5 seconds, reported 0 packages installed, and left 369 MB on disk. The checkout already contained 4,949 files, roughly 481,819 lines of source, and 215.9 MB, reflecting the bundled project and its included OmO source.
No build script or target was present, so our runner skipped it. Node's test command completed in 8 seconds with 9 passed and 0 failed. Npm audit reported 0 known vulnerabilities at every listed severity. The scan found 5 CI workflows, a tests directory, and no Dockerfile. These checks did not run a live multi-agent coding job.
Nine passing tests cover a much larger installed surface
The 9 passing cases cannot certify every installed behavior. Hooks wrap agent actions, MCP helpers launch processes, model categories route work, and plan state decides when execution continues. Run doctor, inspect the generated config in a disposable repository, and verify that uninstall restores the prior Codex setup.
The repository itself is large for a thin distribution: 215.9 MB and nearly 482,000 source lines in our commit. Its architecture diagram points to a Next.js 15 website and an OmO submodule, while the release notes mainly describe synced marketplace payloads. Source contributors therefore need to determine whether a change belongs in LazyCodex, the bundled OmO copy, or the upstream OmO repository before editing.
The 500-iteration mode needs a token budget first
$ulw-loop can run up to 500 iterations in ultrawork mode and 100 in normal mode. Model routing may send small jobs to cheaper models and difficult work to higher-reasoning choices, but category routing does not set a spending ceiling by itself. Before enabling a long loop, cap agent concurrency in Codex, define a completion promise that can be checked, and monitor whether repeated workers are making new progress.
Open issue 145 describes a related control problem. Its report says shipped bootstrap bundles used a subagent limit of 1,000 and a multi-agent limit of 16, and could overwrite lower local settings. The issue includes a proposed bound of 4 and test evidence, yet it remains open. Treat the active installed version and resulting config.toml as the source of truth rather than assuming a README promise controls fan-out.
Issue 114 weakens the verified-completion claim
LazyCodex sells verified completion as a defining feature, which makes issue 114 unusually important. The report reproduces $start-work accepting any nonempty file under .omo/evidence/ as sufficient proof, even when the task's required deliverable is missing. A generic receipt can therefore let later steps run on absent or stale output. Until that gate changes, final verification belongs outside the worker's own receipt protocol.
Issue 160 reports another ownership error in version 4.19.4: when a child stops, a hook can inject the parent's whole plan into that child, causing it to take unrelated tasks and duplicate work. Issue 154 says the LSP hook blocks edits to files outside the session working directory, including sibling projects or worktrees. These reports target the orchestration layer itself, so they matter even if Codex's underlying edit tools work correctly.
A Windows report counted 27 helper copies for 3 chats
Open issue 141 documents 3 active Windows conversations alongside 27 copies each of CodeGraph, Git Bash MCP, and LSP helper processes left resident for hours. The reporter saw memory pressure and interface lag. It is one environment report rather than our result, but the command paths point into the OmO plugin cache. Windows adopters should watch process counts across several completed sessions before relying on long-running desktop use.
The latest release, v4.19.4, arrived on 2026-08-01 and synced the Codex marketplace payload from the matching OmO version. The last code push was 2026-08-09. Issue work continued into September, including a configuration issue closed on September 3 and issue 145 updated on September 2. GitHub listed 3,393 stars and 19 combined issues and pull requests when fetched, so discussion continues despite the quieter source timeline.
Native Codex is the safer default for smaller projects
LazyCodex makes its best case in a sprawling repository that repeatedly needs project memory, planned execution, and specialist review. Our 5-second install and 9 passing tests make a trial cheap, but the open completion, process-lifecycle, and plan-ownership reports rule out a default recommendation. Use a disposable Codex home, set concurrency yourself, and require separate evidence for important results.