Summary
On Windows, the generated omo.cmd launcher exits with code 255 before dispatching to Bun or Node. This breaks direct omo CLI usage, including omo ulw-loop, while the plugin hooks and MCP servers can still load normally.
Environment
- LazyCodex version: 4.19.1
- Codex version: 0.144.5
- OS: Windows 10.0.26200 x64
- Install method:
npx lazycodex-ai install
- Relevant config:
omo@sisyphuslabs enabled; plugin hooks and Git Bash, CodeGraph, and Context7 MCP entries enabled
Repository Decision
- Target repository:
code-yeongyu/lazycodex
- Why this belongs there: the failure is emitted by LazyCodex's generated Windows command wrapper before Codex or the OMO Node runtime starts.
- LazyCodex evidence: the latest
v4.19.1 source at commit 3efc603ac474f5a4f77001641d0b2736dc121e85 generates the malformed conditions in plugins/omo/dist/cli-node/index.js:74482-74483.
- Upstream Codex source evidence: the failure reproduces in an isolated ASCII-only
.cmd snippet without invoking Codex, so upstream Codex is not on the failing path.
Reproduction
-
Install LazyCodex on Windows:
-
Run the generated launcher from the installer bin directory, for example:
& "$env:USERPROFILE\.local\bin\omo.cmd" --version
$LASTEXITCODE
-
Observe the command parser failure before either runtime is invoked.
Minimal isolated reproduction:
@echo off
setlocal EnableExtensions EnableDelayedExpansion
set "OMO_NODE_BINARY=node"
if "!OMO_NODE_BINARY:~0,1!"=="^"" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~1!"
echo SURVIVED
Expected Behavior
omo.cmd --version should print the installed LazyCodex version and exit 0. omo ulw-loop should dispatch to its generated command wrapper.
Actual Behavior
The syntax of the command is incorrect.
exit code: 255
The isolated reproduction fails under both code page 65001 and 437. It also fails with ASCII-only paths, so the behavior is not caused by a non-ASCII Windows user profile.
Evidence
-
Installed wrapper contains:
if "!OMO_NODE_BINARY:~0,1!"=="^"" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~1!"
if "!OMO_NODE_BINARY:~-1!"=="^"" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~0,-1!"
-
Latest source generates those lines in windowsNodeDiscoveryLines():
plugins/omo/dist/cli-node/index.js:74482
plugins/omo/dist/cli-node/index.js:74483
-
The malformed comparison was reproduced twice with exit 255.
-
Replacing only =="^"" with =="""" made the isolated wrapper print SURVIVED=node and exit 0 twice.
-
Running the bundled Node runtime directly still works:
4.19.1
DIRECT_OMO_NODE_EXIT=0
Root Cause
windowsNodeDiscoveryLines() emits =="^"" when it tries to compare the first or last character of OMO_NODE_BINARY with a double quote. That sequence is not valid CMD comparison syntax, so cmd.exe aborts parsing before the wrapper reaches runtime discovery or dispatch. Both windowsCommandShim() and windowsRuntimeWrapper() consume the shared generated lines.
Proposed Fix
Generate the valid CMD quote comparison:
if "!OMO_NODE_BINARY:~0,1!"=="""" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~1!"
if "!OMO_NODE_BINARY:~-1!"=="""" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~0,-1!"
Add a Windows regression test that writes the generated wrapper and executes it through cmd.exe /d /c, rather than only checking the generated text. Cover both quoted and unquoted NODE_REPL_NODE_PATH values because the shared helper is used by component command shims and the root omo.cmd runtime wrapper.
Verification Plan
This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated
Summary
On Windows, the generated
omo.cmdlauncher exits with code 255 before dispatching to Bun or Node. This breaks directomoCLI usage, includingomo ulw-loop, while the plugin hooks and MCP servers can still load normally.Environment
npx lazycodex-ai installomo@sisyphuslabsenabled; plugin hooks and Git Bash, CodeGraph, and Context7 MCP entries enabledRepository Decision
code-yeongyu/lazycodexv4.19.1source at commit3efc603ac474f5a4f77001641d0b2736dc121e85generates the malformed conditions inplugins/omo/dist/cli-node/index.js:74482-74483..cmdsnippet without invoking Codex, so upstream Codex is not on the failing path.Reproduction
Install LazyCodex on Windows:
npx lazycodex-ai installRun the generated launcher from the installer bin directory, for example:
Observe the command parser failure before either runtime is invoked.
Minimal isolated reproduction:
Expected Behavior
omo.cmd --versionshould print the installed LazyCodex version and exit 0.omo ulw-loopshould dispatch to its generated command wrapper.Actual Behavior
The isolated reproduction fails under both code page 65001 and 437. It also fails with ASCII-only paths, so the behavior is not caused by a non-ASCII Windows user profile.
Evidence
Installed wrapper contains:
Latest source generates those lines in
windowsNodeDiscoveryLines():plugins/omo/dist/cli-node/index.js:74482plugins/omo/dist/cli-node/index.js:74483The malformed comparison was reproduced twice with exit 255.
Replacing only
=="^""with==""""made the isolated wrapper printSURVIVED=nodeand exit 0 twice.Running the bundled Node runtime directly still works:
Root Cause
windowsNodeDiscoveryLines()emits=="^""when it tries to compare the first or last character ofOMO_NODE_BINARYwith a double quote. That sequence is not valid CMD comparison syntax, socmd.exeaborts parsing before the wrapper reaches runtime discovery or dispatch. BothwindowsCommandShim()andwindowsRuntimeWrapper()consume the shared generated lines.Proposed Fix
Generate the valid CMD quote comparison:
Add a Windows regression test that writes the generated wrapper and executes it through
cmd.exe /d /c, rather than only checking the generated text. Cover both quoted and unquotedNODE_REPL_NODE_PATHvalues because the shared helper is used by component command shims and the rootomo.cmdruntime wrapper.Verification Plan
omo.cmd --versionprints4.19.1and exits 0 on Windows.omo.cmd ulw-loop --helpreaches the ulw-loop wrapper.NODE_REPL_NODE_PATH.This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated