bunx/npx lazycodex install fails with 404 — 0.1.0 tarball missing from npm

[eddieparc]

Summary

bunx lazycodex install and npx lazycodex install both fail right after the 0.1.0 release announcement. The package appears to be in a broken state on the npm registry — the manifest stub exists but no version is resolvable.

Repro

$ bunx lazycodex install
Resolving dependencies
Resolved, downloaded and extracted [2]
error: Package "lazycodex" with tag "latest" not found, but package exists
error: lazycodex@latest failed to resolve

$ npx -y lazycodex install
npm error code ENOVERSIONS
npm error No versions available for lazycodex

$ bunx lazycodex@0.1.0 install
error: No version matching "0.1.0" found for specifier "lazycodex" (but package exists)

Diagnosis

Hitting the registry directly:

$ curl -s https://registry.npmjs.org/lazycodex
{
  "_id":"lazycodex",
  "name":"lazycodex",
  "time":{
    "created":"2026-05-25T15:45:27.867Z",
    "modified":"2026-05-30T12:59:55.794Z",
    "0.0.0":"2026-05-25T15:45:28.147Z",
    "0.1.0":"2026-05-30T12:40:25.969Z",
    "unpublished":{
      "time":"2026-05-30T12:59:55.794Z",
      "versions":["0.0.0"]
    }
  },
  "_rev":"4-fd913ffe80c7214400b665761828dad6"
}

Notes:

• Manifest has no versions field and no dist-tags — only time stubs remain.
• 0.0.0 is explicitly in unpublished.versions.
• 0.1.0 is not listed as unpublished, but its tarball is gone:

  $ curl -sI https://registry.npmjs.org/lazycodex/-/lazycodex-0.1.0.tgz
  HTTP/2 404
  x-amz-delete-marker: true
  

• 0.0.0 tarball also returns 404.

Timeline suggests an unpublish-during-release glitch: 0.1.0 was published at 12:40, then 0.0.0 was unpublished at 12:59 (19 minutes later). npm's "unpublish the last/only resolvable version → drop the whole package" behavior may have wiped the new version too.

Suggested Fix

• Re-publish 0.1.0 (or bump to 0.1.1)
• Verify npm dist-tag add lazycodex@<ver> latest is set
• Sanity-check with npm view lazycodex dist-tags

Environment

• macOS (darwin)
• bun 1.3.10
• node 24.14.0, npm bundled
• Tried from a clean cwd; no local registry overrides

Happy to test as soon as a republish lands.

[MingyooLee]

I can reproduce the unscoped lazycodex failure as well.

One additional docs/registry issue: the documented equivalent command currently appears unsafe:

bunx omo install --platform=codex

On my machine, unscoped omo resolves to an unrelated npm package:

{
  "name": "omo",
  "version": "2.0.0",
  "description": "Oh my OSS command-line tool",
  "repository": "github.com/fishead/omo",
  "bin": { "omo": "lib/index.js" }
}

bunx omo --help shows an OSS object-management CLI:

Commands:
  object [options] <action> [file-or-dir]  manage Object on OSS

The package that currently resolves and exposes the expected LazyCodex/OmO CLI appears to be:

bunx @code-yeongyu/lazycodex --help

That reports 0.1.2 and shows the expected install|setup, doctor, and get-local-version commands.

So there seem to be two separate issues:

1. The unscoped lazycodex package has no resolvable latest version.
2. The unscoped omo package name points to an unrelated package, so the documented equivalent command may run the wrong CLI.

[eddieparc]

A small follow-up from my side. I tried again today (2026-05-31) and hit the same registry state — bunx lazycodex install still 404s, the manifest still has no versions / no dist-tags, and the 0.1.0 tarball still returns HTTP/2 404 with x-amz-delete-marker: true.

After this, the maintainer kindly replied to me on Threads (post) and pointed me at the omodex branch of code-yeongyu/oh-my-openagent to install from in the meantime. I followed that pointer with my coding agent and ended up with a working install on macOS (darwin-arm64). Sharing the exact steps I ran in case it helps anyone else in the same spot — not suggesting this should be the official path, just recording what worked for me so it's findable.

What I did

# 1. Clone. Shallow + --recurse-submodules failed for me with
#    "fatal: remote error: upload-pack: not our ref ..." on the
#    packages/lsp-tools-mcp submodule. --remote on the submodule
#    update worked instead:
git clone --branch omodex --depth 1 https://github.com/code-yeongyu/oh-my-openagent.git omodex-install
cd omodex-install
git submodule update --init --remote --recursive

# 2. Build
bun install --ignore-scripts
bun run build
npm --prefix packages/lsp-tools-mcp ci   # the omo-codex plugin build invokes tsc against this; missing node_modules made the first attempt fail

# 3. Run the codex installer.
#    bin/oh-my-opencode.js resolved a platform binary that didn't
#    recognize --platform=codex on my machine; invoking the locally
#    built CLI directly worked:
bun run dist/cli/index.js install --no-tui --platform=codex

Last lines I saw on success:

[OK] Codex plugin installed -> ~/.codex/config.toml
oMoMoMoMo... Enjoy!

One thing that tripped me up afterwards

The installer wrote [features.multi_agent_v2] enabled = true to ~/.codex/config.toml. My config already had a legacy [agents] block with max_threads = 6 and max_depth = 2 (carried over from an earlier setup), and codex then refused to start:

Error: failed to load configuration
Caused by:
    agents.max_threads cannot be set when multi_agent_v2 is enabled

I backed up the config and removed the legacy [agents] block and codex loaded again. Flagging it only in case it's something worth surfacing to a fresh user; I don't know what the intended behavior here is.

Final state on my machine

$ codex plugin list | grep -A2 sisyphuslabs
Marketplace `sisyphuslabs`
~/.codex/plugins/cache/sisyphuslabs/.agents/plugins/marketplace.json

PLUGIN            STATUS              VERSION  PATH
omo@sisyphuslabs  installed, enabled  0.1.0    ~/.codex/plugins/cache/sisyphuslabs/omo/0.1.0

Happy to retest a 0.1.0 republish or 0.1.1 whenever it lands. Thanks for the work on this, and thanks again to @code-yeongyu for the Threads pointer.

---

_{This follow-up comment was drafted by an AI coding assistant running on my machine and walking through the install with me; I reviewed and posted it. Reporting that for transparency since the steps are reconstructed from the install transcript rather than written from memory.}