Version v1.14.35 is unable to load OMO normally again

[woodynew]

Description

After updating to the latest version, OMO couldn't load normally. It worked fine after reverting to v1.14.33.

Plugins

OMO

OpenCode version

v1.14.35

Steps to reproduce

The APP prompts you to install and restart v1.14.35
After the restart, only Build and Plan were left, and OMO was not loaded

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The Description field only repeats the title — please provide a meaningful description of what's happening (e.g., what behavior you observe, any error messages or logs)
• Steps to reproduce is empty (_No response_) — please provide steps to reproduce the issue
• Operating System and Terminal fields are empty — please fill these in so maintainers can help debug

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

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

• [BUG] oh-my-openagent works on 1.3.13 but registers nothing on 1.3.14 #21032: oh-my-openagent works on an older version but registers nothing after a version upgrade (same symptom)
• oh-my-openagent v3.15.2 fails to load agents in OpenCode v1.3.15 on Ubuntu 22.04 #21081: oh-my-openagent fails to load agents after an OpenCode version upgrade
• v1.14.32 regression: plugin agents and MCPs silently fail to register (ALS context lost during InstanceStore.boot) #25457: v1.14.32 regression where plugin agents/MCPs silently fail to register (closed — may have been re-introduced)

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thanks for updating the issue! The description and reproduction steps look good now. We appreciate you taking the time to fill these in.

[liu5269]

+1

[Ryker0716]

+1

[weberwang]

+1

[Hona]

Hey can someone with this issue run this and tell me the output pls:

in powershell

$xdg=if($env:XDG_DATA_HOME){$env:XDG_DATA_HOME}else{Join-Path (Join-Path $HOME ".local") "share"}; $paths=@((Join-Path $xdg "opencode\log\*.log")); if($env:APPDATA){$paths+=(Join-Path $env:APPDATA "ai.opencode.desktop\logs\*.log")}; [bool](Select-String -Path $paths -Pattern "ERR_UNSUPPORTED_ESM_URL_SCHEME|Received protocol 'bun:'|bun:sqlite|globalThis\.Bun|Bun is not defined|Cannot destructure property.*globalThis\.Bun|Cannot read properties of undefined.*Bun|failed to load plugin.*oh-my-open(agent|code)" -ErrorAction SilentlyContinue)

[Hona]

Hey, heads up: opencode’s new Electron desktop app runs the embedded server/plugin runtime on Node, not Bun.

oh-my-openagent / oh-my-opencode@3.17.13 appears to be built with bun build --target bun, and the published dist/index.js contains Bun runtime APIs like globalThis.Bun, Bun.file, Bun.write, Bun.spawn, Bun.hash, Bun.serve, Bun.which, and import { Database } from "bun:sqlite".

That means the plugin can work in Bun-backed opencode environments, but it will fail to load in Electron’s Node runtime. A direct Node import repro hits:

ERR_UNSUPPORTED_ESM_URL_SCHEME: Received protocol 'bun:'

What likely needs to change:

• Publish a Node-compatible server plugin entrypoint.
• Avoid --target bun for the server plugin bundle, or provide conditional exports.
• Remove/replace Bun-only APIs in the code loaded by dist/index.js.
• Keep Bun-only code behind a CLI/bin path if needed, but not in the opencode plugin server entrypoint.

This is probably why users switching from Tauri/CLI-style environments to Electron think the plugin “disappeared”: the config is still shared, but Electron cannot load the plugin.