Windows: generated omo.cmd uses invalid quote comparison and exits 255

从 plugins/omo/dist/cli-node/index.js 中的 windowsNodeDiscoveryLines() 开始，然后使用带引号和不带引号的 NODE_REPL_NODE_PATH 值，通过 cmd.exe /d /c 复现生成的 wrapper。为组件 shim 和 root omo.cmd wrapper 都添加 Windows 回归覆盖，并确认 --version 和 ulw-loop --help 执行成功，同时现有的 installer 和 bootstrap 测试仍保持通过。

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

1. Install LazyCodex on Windows:

   npx lazycodex-ai install
   

2. Run the generated launcher from the installer bin directory, for example:

   & "$env:USERPROFILE\.local\bin\omo.cmd" --version
   $LASTEXITCODE
   

3. 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

• omo.cmd --version prints 4.19.1 and exits 0 on Windows.
• omo.cmd ulw-loop --help reaches the ulw-loop wrapper.
• Generated wrappers accept quoted and unquoted NODE_REPL_NODE_PATH.
• The wrapper succeeds under Windows code pages 65001 and 437.
• Existing Codex plugin installer and bootstrap tests remain green.

---

This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated