fix: invalidate opencode plugin cache on global install

[popododo0720]

Summary

• Fixes stale plugin version after bun install -g oh-my-opencode by invalidating opencode's plugin cache in the postinstall script.

Problem

When users run bun install -g oh-my-opencode, only the global npm package at ~/.bun/install/global/node_modules/ is updated. However, opencode resolves plugins from its own separate cache at $XDG_CACHE_HOME/opencode/node_modules/ with its own bun.lock. The stale cached version continues to be loaded on subsequent launches, causing version mismatch.

Solution

The postinstall.mjs script now:

1. Detects the opencode cache directory using xdg-basedir (same as opencode on all platforms)
2. Removes node_modules/oh-my-opencode (stale cached module)
3. Removes bun.lock and bun.lockb (required because bun reinstalls the exact pinned version from the lock entry)
4. Guards with existsSync to skip if cache doesn't exist (fresh install)
5. Wraps main() with .catch() to never fail the install process
6. Warns on real deletion errors (EPERM/EBUSY) instead of silently swallowing them

---

Summary by cubic

Invalidate opencode’s plugin cache on global install so the latest oh-my-opencode is loaded on next launch. Prevents stale versions after bun install -g oh-my-opencode.

• Bug Fixes
  • postinstall.mjs deletes cached oh-my-opencode and bun.lock/bun.lockb under $XDG_CACHE_HOME/opencode (defaults to ~/.cache/opencode) to force re-resolve.
  • Skips if the cache is missing; warns on real deletion errors without failing install.
  • Keeps platform binary verification; wraps main in a safe async flow.

^{Written for commit 483f2b0. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 1 file

Confidence score: 2/5

• There’s a high-risk behavior in postinstall.mjs where shared bun.lock/bun.lockb files in the opencode cache are deleted, which can unpin versions for other plugins and cause unpredictable installs.
• Given the severity (8/10) and potential cross-plugin impact, merge risk is elevated despite the small surface area of change.
• Pay close attention to postinstall.mjs - deletes shared lockfiles and may affect other plugin installs.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="postinstall.mjs">

<violation number="1" location="postinstall.mjs:60">
P1: Destructive deletion of shared lockfiles unpins versions for all other installed opencode plugins. The code at `postinstall.mjs` deletes the entire `bun.lock` and `bun.lockb` files from the opencode cache directory, which are shared across all plugins. This unpins versions of all other installed plugins and may cause them to update to incompatible versions on next startup. Consider using a more scoped invalidation mechanism that only removes the specific plugin's lockfile entries.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P1: Destructive deletion of shared lockfiles unpins versions for all other installed opencode plugins. The code at postinstall.mjs deletes the entire bun.lock and bun.lockb files from the opencode cache directory, which are shared across all plugins. This unpins versions of all other installed plugins and may cause them to update to incompatible versions on next startup. Consider using a more scoped invalidation mechanism that only removes the specific plugin's lockfile entries.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At postinstall.mjs, line 60:

<comment>Destructive deletion of shared lockfiles unpins versions for all other installed opencode plugins. The code at `postinstall.mjs` deletes the entire `bun.lock` and `bun.lockb` files from the opencode cache directory, which are shared across all plugins. This unpins versions of all other installed plugins and may cause them to update to incompatible versions on next startup. Consider using a more scoped invalidation mechanism that only removes the specific plugin's lockfile entries.</comment>

<file context>
@@ -22,7 +27,52 @@ function getLibcFamily() {
+
+  const targets = [
+    join(cacheBase, "node_modules", "oh-my-opencode"),
+    join(cacheBase, "bun.lock"),
+    join(cacheBase, "bun.lockb"),
+  ];
</file context>

[popododo0720]

Re: lockfile deletion concern (identified by cubic) — this is an intentional trade-off.

Without deleting the lockfiles, bun install reinstalls the exact pinned (stale) version from the lock entry, making the entire cache invalidation ineffective. Confirmed through real user testing.

The blast radius is limited: ~/.cache/opencode/ is ephemeral by nature. All plugins re-resolve to their latest compatible versions on next opencode startup, which is expected behavior for a cache directory.