bun install -g @opencode-ai/cli@next fails with "No version matching 0.0.0-next-17055 (but package exists)" on bun 1.3.11

[leiyunkang7]

Bug: bun install -g @opencode-ai/cli@next fails with No version matching "0.0.0-next-17055" (but package exists) on bun 1.3.11

Summary

Installing the next dist-tag of the OpenCode CLI via bun fails even though the
binary sub-package is in fact published on the npm registry. bun's resolver
rejects the prerelease version 0.0.0-next-17055 while the npm CLI (11.13.0)
and the registry itself both confirm the version exists. This blocks the
official one-liner install for the next channel on Windows / unix where users
have bun as their primary package manager.

Environment

• bun 1.3.11 (af24e281) — installed via the official bun-windows-x64.zip installer
• node v26.1.0
• npm 11.13.0
• OS: Windows 10 10.0.26200.8457
• Install channel: next (currently 0.0.0-next-17055)
• Network: behind an HTTP proxy (HTTP_PROXY=http://127.0.0.1:7897) — also
  tried without proxy, same result
• Fresh global cache (manually deleted ~/.bun/install/cache/opencode-* and
  ~/.bun/install/global/node_modules/@opencode-ai/ between attempts)

Reproduction

bun install -g --trust @opencode-ai/cli@next

Actual output (verbatim)

bun add v1.3.11 (af24e281)
   - "@opencode-ai/cli": "next" - @opencode-ai/cli@0.0.0-next-17055
Clean lockfile: 15 packages - 15 packages in 100us
Skip installing opencode-darwin-arm64 - cpu & os mismatch
Skip installing opencode-darwin-x64 - os mismatch
Skip installing opencode-darwin-x64-baseline - os mismatch
Skip installing opencode-linux-arm64 - cpu mismatch
Skip installing opencode-linux-arm64-musl - cpu & os mismatch
Skip installing opencode-linux-x64 - os mismatch
Skip installing opencode-linux-x64-baseline - os mismatch
Skip installing opencode-linux-x64-baseline-musl - os mismatch
Skip installing opencode-linux-x64-musl - os mismatch
Skip installing opencode-windows-arm64 - cpu mismatch
[Scripts] Starting scripts for "@opencode-ai/cli"
Failed to install OpenCode. Try manually installing "@opencode-ai/cli-windows-x64" or "@opencode-ai/cli-windows-x64-baseline".
error: postinstall script from "@opencode-ai/cli" exited with 1

What I've verified

The "missing" binary sub-package is in fact published on npm. Reproducing
exactly what the failed postinstall script was trying to do:

$ bun add -g @opencode-ai/cli-windows-x64@0.0.0-next-17055
bun add v1.3.11 (af24e281)
Resolving dependencies
Resolved, downloaded and extracted [1]
error: No version matching "0.0.0-next-17055" found for specifier "@opencode-ai/cli-windows-x64" (but package exists)
error: @opencode-ai/cli-windows-x64@0.0.0-next-17055 failed to resolve

Direct query against the npm registry:

$ curl -sL https://registry.npmjs.org/@opencode-ai/cli-windows-x64 | jq '.versions["0.0.0-next-17055"].dist'
{
  "shasum": "6e186d9fc245421d...",
  "tarball": "https://registry.npmjs.org/@opencode-ai/cli-windows-x64/-/cli-windows-x64-0.0.0-next-17055.tgz"
}

The package is there, but bun 1.3.11 explicitly reports (but package exists)
and refuses to resolve.

Same install with the npm CLI succeeds:

$ npm install -g @opencode-ai/cli-windows-x64@0.0.0-next-17055 --registry=https://registry.npmjs.org/
changed 1 package in 5s

$ ~/.npm-global/lib/node_modules/@opencode-ai/cli-windows-x64/bin/opencode2.exe --version
opencode2 v0.0.0-next-17055

So this is not the same root cause as #39802 (which was a genuine
@opencode-ai/cli-linux-x64@0.0.0-next-16570 ETARGET — the binary sub-package
had not been published). In our case the binary sub-package is published;
the resolver on the bun client side is rejecting the prerelease version string.

Why this matters

For users on Windows who have bun as their primary global package manager (a
very common setup — the official sst/opencode README documents npm install -g @opencode-ai/cli first, but bun is the recommended runtime inside the
project's own scripts), pinning to the next channel is currently impossible
without manually invoking the npm CLI as a workaround. This also breaks
bunx @opencode-ai/cli@next, which is the same code path.

Same cli with the latest dist-tag installs fine on bun 1.3.11:

$ bun install -g @opencode-ai/cli
$ ~/.bun/bin/opencode.exe --version
1.18.15

So it's specifically the 0.0.0-next-XXXXX prerelease version range that
bun 1.3.11 rejects.

Expected behaviour

bun install -g @opencode-ai/cli@next should complete the same way
bun install -g @opencode-ai/cli (latest) does — installing the meta package
and letting the postinstall script pull down the matching
@opencode-ai/cli-windows-x64 binary sub-package.

Workaround (worked for me)

npm install -g @opencode-ai/cli-windows-x64@0.0.0-next-17055 --registry=https://registry.npmjs.org/
# rename the binary it ships:
cp "$(npm root -g)/@opencode-ai/cli-windows-x64/bin/opencode2.exe" ~/.bun/bin/opencode-next.exe

But this obviously doesn't scale for normal users.

Related

• npm install -g @opencode-ai/cli@next on WSL2 incorrect. #39802 — same failure mode with a different root cause (the binary sub-package
  was genuinely unpublished in 0.0.0-next-16570). Worth tracking both
  together because the user-facing error message is identical.
• The bun registry resolver rejecting prerelease versions that have a
  non-alpha/beta/rc tag (e.g. next) may be a general bun upstream bug
  worth filing separately there.

[opencode-agent]

I couldn't reproduce this as a prerelease-semver resolution failure. Using Bun 1.3.11 (af24e281) against the public npm registry, both exact Windows packages resolve successfully:

bun add --lockfile-only @opencode-ai/cli-windows-x64@0.0.0-next-17055
bun add --lockfile-only @opencode-ai/cli-windows-x64-baseline@0.0.0-next-17055

The version was published shortly before this report. Also, the successful npm command explicitly forces registry.npmjs.org, while the failing Bun command does not. That points to stale package metadata in Bun's cache or a configured registry mirror/proxy, rather than Bun rejecting the -next version.

Could you please try:

bun pm cache rm
bun add -g --trust @opencode-ai/cli@next --registry=https://registry.npmjs.org

If it still fails, please share whether a registry is configured in bunfig.toml (redacting any credentials). That will distinguish a Windows-specific Bun resolver problem from stale registry metadata.