OMO 4.8.1 hooks fail because plugin package omits components dist CLIs

[IndianMarshmello]

Summary

On Ubuntu 24.04 with OMO/LazyCodex plugin 4.8.1, the configured PreToolUse, PostToolUse, Stop, and related hooks fail before they can parse hook input because the installed plugin cache is missing the built component CLI files referenced by hooks/hooks.json.

The failure is not caused by hook JSON shape or timeout behavior. Directly invoking the configured hook commands exits with Node MODULE_NOT_FOUND for components/<component>/dist/cli.js.

Environment

• OS: Ubuntu 24.04.4 LTS, Linux 6.8.0-124-generic x86_64
• Node: v24.16.0
• OMO install metadata: /home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/4.8.1/lazycodex-install.json
  • packageName: oh-my-opencode
  • version: 4.8.1
• OMO plugin package metadata: @sisyphuslabs/omo-codex-plugin 4.8.1
• Codex config has plugin hooks enabled and OMO enabled:
  • plugin_hooks = true
  • [plugins."omo@sisyphuslabs"] enabled = true

Reproduction

1. Install/enable OMO 4.8.1 for Codex with plugin hooks enabled.
2. Trigger any hook whose command points at a component dist CLI, for example PreToolUse on Bash, PostToolUse after an edit, or Stop.
3. Or directly invoke one configured command:

PLUGIN_ROOT=/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/4.8.1
printf '{}' | node "$PLUGIN_ROOT/components/git-bash/dist/cli.js" hook pre-tool-use

Expected Behavior

The installed plugin cache should contain the built hook CLIs referenced by hooks/hooks.json, and the hook command should start successfully. It may then accept or reject the hook input according to its own logic, but it should not fail at module resolution.

Actual Behavior

Every tested component hook command fails with MODULE_NOT_FOUND because dist/cli.js is absent.

Example:

Error: Cannot find module '/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/4.8.1/components/git-bash/dist/cli.js'
code: 'MODULE_NOT_FOUND'
Node.js v24.16.0
exit=1

The same failure reproduces for these configured hook components:

git-bash
ulw-loop
comment-checker
lsp
rules
start-work-continuation

Evidence

hooks/hooks.json in the installed OMO 4.8.1 cache points hooks at built component CLIs, for example:

"command": "node \"${PLUGIN_ROOT}/components/git-bash/dist/cli.js\" hook pre-tool-use"
"command": "node \"${PLUGIN_ROOT}/components/comment-checker/dist/cli.js\" hook post-tool-use"
"command": "node \"${PLUGIN_ROOT}/components/lsp/dist/cli.js\" hook post-tool-use"
"command": "node \"${PLUGIN_ROOT}/components/start-work-continuation/dist/cli.js\" hook stop"

But the installed 4.8.1 cache contains no component dist/cli.js files:

find /home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/4.8.1/components \
  -maxdepth 3 -path '*/dist/cli.js' -print

Observed output: empty.

The older installed OMO 0.1.0 cache on the same machine does contain the expected built CLIs:

/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/0.1.0/components/comment-checker/dist/cli.js
/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/0.1.0/components/git-bash/dist/cli.js
/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/0.1.0/components/lsp/dist/cli.js
/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/0.1.0/components/rules/dist/cli.js
/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/0.1.0/components/start-work-continuation/dist/cli.js
/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/0.1.0/components/telemetry/dist/cli.js
/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/0.1.0/components/ultrawork/dist/cli.js
/home/uadmin/.codex/plugins/cache/sisyphuslabs/omo/0.1.0/components/ulw-loop/dist/cli.js

The 4.8.1 component directories appear to contain TypeScript source, tests, tsconfig files, and package metadata, but not built dist outputs. Component package manifests still declare bins/files that expect dist, for example ./dist/cli.js.

I also checked current upstream Codex hook execution source. Codex plugin hook discovery injects PLUGIN_ROOT/PLUGIN_DATA, expands plugin hook entries, then the command runner spawns the configured command and writes the hook JSON to stdin. That behavior is consistent with this failure: the configured command path is invalid before stdin shape, matcher behavior, or timeout handling can matter.

Root Cause Assessment

This looks like an OMO/LazyCodex packaging or installation regression in 4.8.1: the active plugin cache contains component source trees but omits the build artifacts that hooks/hooks.json requires.

This is distinct from the previously closed Windows/nvm incomplete-cache report because this reproduction is on Linux and specifically shows OMO 4.8.1 installed with source-only component directories and missing all hook component dist/cli.js files.

Proposed Fix

• Ensure the OMO plugin release/install flow builds or packages components/*/dist/cli.js for every component referenced from hooks/hooks.json.
• Add an install/release smoke test that parses hooks/hooks.json, resolves ${PLUGIN_ROOT}, and asserts every referenced node .../dist/cli.js target exists.
• Add a minimal runtime smoke test for each hook CLI target, either using valid minimal hook fixtures or a deterministic help/version path.
• Fail install or preserve the previous active plugin cache if required hook command targets are missing after promotion.

Verification Plan

1. Install the fixed OMO version into a fresh ~/.codex plugin cache.
2. Confirm this returns every hook component CLI referenced by hooks/hooks.json:

   find ~/.codex/plugins/cache/sisyphuslabs/omo/<version>/components \
     -maxdepth 3 -path '*/dist/cli.js' -print | sort

3. Directly invoke representative hooks and confirm they no longer fail with MODULE_NOT_FOUND.
4. Trigger PreToolUse, PostToolUse, Stop, and SessionStart in Codex and confirm hook failures disappear.
5. Keep the upstream Codex contract check: PLUGIN_ROOT expansion and command spawning should not require an upstream Codex change for this failure mode.

---

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

[mouyase]

Additional Reproduction And Root-Cause Evidence

I reproduced the same failure on macOS after a fresh latest install, and the evidence points to the packaged LazyCodex/OMO install path rather than upstream Codex.

Environment

• OS: macOS
• Install method: npx lazycodex-ai install
• Relevant config: ~/.codex/config.toml has plugin_hooks = true
• Active plugin cache: ~/.codex/plugins/cache/sisyphuslabs/omo/4.8.1
• Hook config source: ~/.codex/plugins/cache/sisyphuslabs/omo/4.8.1/hooks/hooks.json

User-visible Failure

On first launch after install, Codex reported repeated hook failures such as:

SessionStart hook (failed)
error: hook exited with code 1

UserPromptSubmit hook (failed)
error: hook exited with code 1

Stop hook (failed)
error: hook exited with code 1

Direct invocation confirmed MODULE_NOT_FOUND, for example:

Error: Cannot find module '/Users/mouyase/.codex/plugins/cache/sisyphuslabs/omo/4.8.1/components/rules/dist/cli.js'

I confirmed equivalent missing entrypoints for multiple configured hook components, including:

components/rules/dist/cli.js
components/telemetry/dist/cli.js
components/ultrawork/dist/cli.js
components/ulw-loop/dist/cli.js
components/start-work-continuation/dist/cli.js
components/lsp/dist/cli.js

Packaged-Install Root Cause Evidence

The missing dist/cli.js files are not just absent from the cache. The packaged install flow appears to skip building them, and the packaged plugin payload itself does not contain them.

1. Packaged installer skips source build

In the installed oh-my-openagent package, packages/omo-codex/scripts/install/source-package-build.mjs returns false for packaged installers such as lazycodex-ai / oh-my-openagent, so this path does not build plugin source during install.

2. Cache promotion without component builds

packages/omo-codex/scripts/install/cache.mjs uses buildSource=false on that packaged path and then performs cache preparation without generating the hook component dist/cli.js outputs.

3. Published packaged source already lacks the hook artifacts

Under the installed package source tree:

~/.bun/install/global/node_modules/oh-my-openagent/packages/omo-codex/plugin/components/

several hook component directories did not contain dist/ at all, even though hooks/hooks.json references those dist/cli.js entrypoints.

Upstream Codex Routing Evidence

I also checked clean upstream Codex source under /tmp/openai-codex-source.

Relevant upstream files such as:

• codex-rs/core-plugins/src/loader.rs
• codex-rs/core-plugins/src/manager.rs

show hook discovery/loading behavior, but there is no LazyCodex/OMO packaged installer logic there. Upstream Codex loads plugin hook config and executes the configured commands; it does not own the missing OMO component build artifacts.

That makes this a code-yeongyu/lazycodex / packaged OMO installer issue rather than an openai/codex core hook issue.

Local Workaround

I was able to recover the local environment by manually building the missing cache artifacts:

1. cd ~/.codex/plugins/cache/sisyphuslabs/omo/4.8.1
2. npm ci
3. Build the missing component CLIs

After that, the SessionStart, UserPromptSubmit, and Stop hook failures stopped reproducing locally.

This supports the conclusion that the primary defect is missing packaged/built hook component artifacts, not invalid hook JSON or upstream hook execution semantics.

---

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

[code-yeongyu]

Fixed in code-yeongyu/oh-my-openagent@b4c96895c (dev, will ship in the next release).

Your diagnosis was almost exactly right, with one twist we confirmed from the 4.8.1 CI logs: the components were built during the release, but only after oh-my-opencode/oh-my-openagent had already been packed — the lazycodex-ai tarball (packed after the build step) actually shipped dist correctly. Since the installer materializes the plugin cache from the oh-my-openagent/oh-my-opencode package (your lazycodex-install.json shows packageName: oh-my-opencode), the cache ended up source-only and every hook died with MODULE_NOT_FOUND.

Two fixes landed, matching your proposed plan:

• The component build now runs before any of the three packages packs, gated on whichever publishes, with a workflow test pinning that ordering so it can't regress.
• An install-time guard parses hooks/hooks.json, resolves every ${PLUGIN_ROOT} command target, and refuses to activate a payload with missing files — a broken release can no longer replace a working plugin cache.

Verified by packing the real repo and running your exact repro (printf '{}' | node …/components/git-bash/dist/cli.js hook pre-tool-use) against the extracted tarball: exit 0, all 8 components ship dist/cli.js. Excellent report — the 0.1.0-vs-4.8.1 cache comparison was the key clue.