Plugins configured with @latest never auto-update: bun registry cache + stale isOutdated check

[conversun]

Description

Plugins configured with @latest (or no version) never auto-update on subsequent OpenCode starts, requiring manual cache deletion:

rm -rf ~/.cache/opencode/node_modules/<plugin-name>
rm ~/.cache/opencode/bun.lock

This affects all plugins using @latest — not just a specific one. For example, with this config:

{
  "plugin": ["oh-my-opencode@latest", "opencode-supermemory@latest"]
}

Both plugins get frozen at whatever version was @latest at first install.

Root Cause

The isOutdated check in packages/opencode/src/bun/registry.ts uses bun info <pkg> version (via subprocess) to query the latest version. This has two failure modes:

1. Bun's registry cache returns stale data

bun info caches npm registry responses. When a new plugin version is published, bun info may return the old version from its cache, causing isOutdated() to return false — skipping the update.

2. Network failures silently suppress updates

If bun info fails for any reason (proxy issues, DNS resolution, timeouts), the function returns null, and isOutdated() falls back to return false — "not outdated". Users behind corporate proxies or tools like Surge (Fake-IP mode) are particularly affected since bun info subprocess may fail while fetch() would work fine.

Additionally, in packages/opencode/src/bun/index.ts, --no-cache is only passed to bun add when proxied() || process.env.CI. So even when isOutdated correctly detects a new version, bun add --force may still install from bun's package cache instead of fetching the new version from npm.

Evidence

File	Cached Version	npm @latest
oh-my-opencode	3.11.0	3.11.1
opencode-supermemory	2.0.2	2.0.4

Cache package.json stores exact resolved versions (e.g., "3.11.0" not "latest"), and the isOutdated check fails to detect newer versions due to the issues above.

Suggested Fix

1. Replace bun info with direct HTTP fetch to npm registry in registry.ts — avoids bun's registry cache entirely and is more reliable behind proxies
2. Always use --no-cache for bun add when version === "latest" — ensures bun fetches fresh package data when updating plugins

See linked PR for implementation.

Related Issues

• Plugins with implied latest version don't auto-update on restart #6774
• Plugin updates: No way to get latest version after initial install #10546
• Plugins using npm dist-tags (e.g. @dev) never auto-update due to bun lockfile caching #12712
• [bug] Plugin 'oh-my-opencode' fails to auto-update via bun, causing persistent '[config-context]' warnings #15673

OpenCode version

v1.2.21

Operating System

macOS (also affects all platforms)

Steps to reproduce

1. Configure a plugin with @latest: "plugin": ["some-plugin@latest"]
2. Start OpenCode — plugin installs at current latest (e.g., v1.0.0)
3. Plugin author publishes v1.0.1
4. Restart OpenCode — still uses v1.0.0
5. Only manual rm -rf ~/.cache/opencode/node_modules/some-plugin && rm ~/.cache/opencode/bun.lock triggers the update

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Plugins with implied latest version don't auto-update on restart #6774: Plugins with implied latest version don't auto-update on restart
• Plugin updates: No way to get latest version after initial install #10546: Plugin updates: No way to get latest version after initial install
• Plugins using npm dist-tags (e.g. @dev) never auto-update due to bun lockfile caching #12712: Plugins using npm dist-tags (e.g. @dev) never auto-update due to bun lockfile caching
• [bug] Plugin 'oh-my-opencode' fails to auto-update via bun, causing persistent '[config-context]' warnings #15673: [bug] Plugin 'oh-my-opencode' fails to auto-update via bun, causing persistent warnings

These issues appear to describe the same root cause and symptoms. You've already referenced them — it may be worth adding your findings there or confirming whether this is a distinct issue.

[ghost91-]

To be honest, I think the fix is much simpler. Using bun info is fine. It's just the implementation that's broken. It tries to read stdout and stderr of a stream after it has already exited, which does not work. So you always run into the

Failed to resolve latest version, using cached

case.

The fix is simple: Read stdout and stderr before the stream exits. The same approach is used in Process.run in process.ts:

    const [code, stdout, stderr] = await Promise.all([proc.exited, buffer(proc.stdout), buffer(proc.stderr)])

I'll create a minimal PR to fix this bug.