Describe the bug
I’m trying to use the micode plugin with the latest OpenCode Desktop (Electron-based) on Windows 11. The plugin appears in the top-right corner of the UI, but none of the custom commands (/init, /ledger, /search) work – only the native OpenCode commands are executed. After checking the logs, I found that the plugin fails to load due to a bun: protocol error.
Full error from log:
ERROR 2026-05-11T15:16:30 +5125ms service=plugin path=micode target=file:///C:/Users/joage/.cache/opencode/packages/micode@latest/node_modules/micode/dist/index.js error=Only URLs with a scheme in: file, data, node, and electron are supported by the default ESM loader. Received protocol 'bun:' failed to load plugin
This indicates that the built JavaScript file (dist/index.js) contains imports or references using bun: (e.g. bun:fs, bun:path), which are not available in Node.js / Electron runtime.
Environment
OS: Windows 11
OpenCode version: 1.14.48
micode version: latest (as of 2026-05-11)
Installation type: Desktop app (Electron)
Node.js / Electron runtime in OpenCode: Standard Node.js ESM loader
To Reproduce
Install OpenCode Desktop v1.14.48 on Windows 11.
Add "plugin": ["micode"] to %USERPROFILE%.config\opencode\opencode.json.
Restart OpenCode.
Open the TUI and type /init or /ledger.
Observe that only the native OpenCode commands are executed.
Check the log file under %USERPROFILE%.local\share\opencode\log\ – the error shown above is present.
Expected behavior
The plugin should load successfully and correctly override/register custom commands like /init, /ledger, and /search on the Electron/Node.js runtime of OpenCode Desktop.
Cause analysis
The plugin’s compiled output (dist/index.js) uses Bun‑specific protocols (e.g., bun:path, bun:fs, etc.). These are not supported by the Node.js ESM loader, which is what the Electron app uses under the hood. Since the plugin cannot be loaded at all, OpenCode falls back to its built-in commands.
Note: OpenCode officially documents that plugins run in the same runtime as the host app (which is Node.js in the desktop version). Therefore, the plugin must be built as a plain Node.js package without Bun‑only dependencies.
Possible solutions (request)
Could you please provide a Node.js‑compatible build of the micode plugin? For example:
Ensure that no bun: imports are used in the published bundle.
Build the plugin with a Node.js target (e.g., using esbuild or tsc with proper polyfills for any necessary Bun APIs).
Alternatively, publish a separate package or flag that produces a Node/Electron‑safe artifact.
Additional context
I have already cleared the OpenCode cache (%USERPROFILE%.cache\opencode) and reconfigured the plugin, but the error persists identically.
The plugin seems to work fine for some users (possibly those running OpenCode CLI via Bun, or on macOS where Bun might be installed). However, Windows desktop users with only Node.js are blocked.
OpenCode docs on plugin development: https://opencode.ai/docs/plugins/
Thank you for your work on this plugin – it looks really promising, and I’d love to use it in my workflow!
Describe the bug
I’m trying to use the micode plugin with the latest OpenCode Desktop (Electron-based) on Windows 11. The plugin appears in the top-right corner of the UI, but none of the custom commands (/init, /ledger, /search) work – only the native OpenCode commands are executed. After checking the logs, I found that the plugin fails to load due to a bun: protocol error.
Full error from log:
ERROR 2026-05-11T15:16:30 +5125ms service=plugin path=micode target=file:///C:/Users/joage/.cache/opencode/packages/micode@latest/node_modules/micode/dist/index.js error=Only URLs with a scheme in: file, data, node, and electron are supported by the default ESM loader. Received protocol 'bun:' failed to load plugin
This indicates that the built JavaScript file (dist/index.js) contains imports or references using bun: (e.g. bun:fs, bun:path), which are not available in Node.js / Electron runtime.
Environment
OS: Windows 11
OpenCode version: 1.14.48
micode version: latest (as of 2026-05-11)
Installation type: Desktop app (Electron)
Node.js / Electron runtime in OpenCode: Standard Node.js ESM loader
To Reproduce
Install OpenCode Desktop v1.14.48 on Windows 11.
Add "plugin": ["micode"] to %USERPROFILE%.config\opencode\opencode.json.
Restart OpenCode.
Open the TUI and type /init or /ledger.
Observe that only the native OpenCode commands are executed.
Check the log file under %USERPROFILE%.local\share\opencode\log\ – the error shown above is present.
Expected behavior
The plugin should load successfully and correctly override/register custom commands like /init, /ledger, and /search on the Electron/Node.js runtime of OpenCode Desktop.
Cause analysis
The plugin’s compiled output (dist/index.js) uses Bun‑specific protocols (e.g., bun:path, bun:fs, etc.). These are not supported by the Node.js ESM loader, which is what the Electron app uses under the hood. Since the plugin cannot be loaded at all, OpenCode falls back to its built-in commands.
Note: OpenCode officially documents that plugins run in the same runtime as the host app (which is Node.js in the desktop version). Therefore, the plugin must be built as a plain Node.js package without Bun‑only dependencies.
Possible solutions (request)
Could you please provide a Node.js‑compatible build of the micode plugin? For example:
Ensure that no bun: imports are used in the published bundle.
Build the plugin with a Node.js target (e.g., using esbuild or tsc with proper polyfills for any necessary Bun APIs).
Alternatively, publish a separate package or flag that produces a Node/Electron‑safe artifact.
Additional context
I have already cleared the OpenCode cache (%USERPROFILE%.cache\opencode) and reconfigured the plugin, but the error persists identically.
The plugin seems to work fine for some users (possibly those running OpenCode CLI via Bun, or on macOS where Bun might be installed). However, Windows desktop users with only Node.js are blocked.
OpenCode docs on plugin development: https://opencode.ai/docs/plugins/
Thank you for your work on this plugin – it looks really promising, and I’d love to use it in my workflow!