Repository navigation
[FEATURE] Ship a Node-compatible entry so oh-my-openagent loads on OpenCode Desktop (Node ESM sidecar, no Bun required) #7486
Description
Context
OpenCode Desktop loads plugins through a Node ESM plugin host (dynamic import()), not Bun. oh-my-openagent is Bun-targeted, so it currently fails to load on OpenCode Desktop. This is tracked on the OpenCode side as anomalyco/opencode#41033; the earlier anomalyco/opencode#6635 was a false alarm (packaging is actually fine — a clean install from both the China mirror and the official npm registry imports OK under plain Node with identical tarball hashes).
Request
Please provide a way to run omo on OpenCode Desktop without requiring Bun, e.g.:
- Ship a Node ESM-compatible build (no top-level Bun-only APIs evaluated at
import()time), or - Document a supported path (e.g. a Node-side shim, or a separate
oh-my-openagent-nodeentry point), or - Confirm whether waiting for OpenCode to bundle a Bun/V2 sidecar is the intended path, and what omo would need to do to support it.
Why it matters
A large share of Desktop users — especially in regions where installing/running Bun is constrained — currently cannot use omo at all. A Node-compatible entry would unblock them without depending on a Bun runtime being present.
Happy to help test any Node-compatible build (I can run node --input-type=module -e "await import('oh-my-openagent')" and report exact behavior).
Activity
liudongyan13701205717-source commentedon Oct 1, 2026
Status check, plus one piece of information that has changed.
Still blocked on the same upstream dependency —
anomalyco/opencode#41033(Bun/V2 sidecar for Desktop). Nothing has landed there from my side, so this remains open on our end and there is no new movement to report.New relevant datapoint: a maintained per-server reconnect endpoint now exists in the OpenCode server (
POST /mcp/<name>/connect), confirmed in analysis onanomalyco/opencode#48743. It does not fix plugin loading, but it does mean a plugin that loads and later drops can be recovered without restarting the app. Relevant to whichever load path you end up shipping.On the Bun constraint: the blocker on my side is unchanged — I cannot guarantee a Bun runtime on target machines, so a Node ESM entry is the only path I can both install and test. For any build you produce I can run and report exact behaviour of:
from a clean Node environment with no Bun present, and include the resolved tarball hashes so packaging differences are visible.
One question that would help triage: is a Bun-only path acceptable as a documented fallback if a Node entry proves to be a large lift (e.g. it needs a top-level-await shim or a bundled sidecar)? Or is Node a hard requirement specifically because Bun cannot be installed in the target environments?
The answer decides which of the three options in the original request is actually worth building — if Bun-only is acceptable as a fallback, option (1) can ship without blocking on (2), and I would rather you spend the effort on the single-load-path fix than on three paths.
code-yeongyu commentedon Nov 2, 2026
Thanks @liudongyan13701205717-source for laying out the Node ESM plugin host situation on OpenCode Desktop and for confirming the tarball imports cleanly under plain Node. Sorry this sat for so long. This is noted as a feature request for a Node-compatible entry, and your offer to test with the node import command is appreciated.