You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] 「V2 (next-17444)」local .ts plugins fail to load on Windows #42763
A local plugin at ~/.config/opencode/plugins/rtk.ts (also referenced as "./plugins/rtk.ts" in global config) fails to load.
Server log:
msg="loading plugin" entrypoint="C:/Users/Me0wo/.config/opencode/plugins/rtk.ts?mtime=1786781760442"
message="failed to load plugin" cause="Die(ResolveMessage: Cannot find module 'C:\Users\Me0wo\.config\opencode\plugins\rtk.ts?mtime=1786781760442' from '')"
/api/plugin shows only internal opencode.* plugins; no user plugin loads.
The supervisor (packages/core/src/plugin/supervisor.ts) imports local files as <abs-path>?mtime=<int> (mtime is always defined so the file:// entrypoint branch is never taken). Standalone bun on the same machine resolves that specifier fine, but the compiled opencode2 binary fails with "Cannot find module ... from ''" looks like the same compiled-binary + query-specifier issue class as #41891, but for core plugin loading and with integer mtimes.
macOS/Linux unaffected.
Plugins
rtk
OpenCode version
V2 (next-17444)
Steps to reproduce
Put any valid V2 plugin .ts (default export = Plugin.define) in ~/.config/opencode/plugins/, watch the server log.
Same failure on beta-17728, and it hits the TUI too: local plugin files break in the TUI client (plugins/tui/ discovery and cli.json path entries) as well as server-side. A few data points that might help:
Windows bun 1.3.14: import("C:/.../x.js") fails even without ?mtime=; import("file:///C:/.../x.js?mtime=...") works.
Same probe on Linux (WSL): POSIX absolute path + ?mtime= resolves fine.
In the TUI, plugins installed into the package cache load fine (plain file:// entrypoint).
FWIW standalone bun here also fails the raw drive path, which differs from what you saw — possibly version-dependent.
Both broken forms are documented usage (/docs/cli/plugins).
This is fixed on dev. I could not reproduce it on Windows 11 at 16c338372a.
Server: local plugins load and run setup. I tested a standalone plugins/rtk.ts, a plugin directory with a relative import, a "./relative" entry in opencode.json, and a project .opencode/plugins/ plugin.
TUI:plugins/<dir>/tui.ts discovery and cli.json"./relative" entries both load.
Compiled binary: all of these also load in a --single build compiled with Bun 1.4.2, the same version CI uses for releases.
Cause: plugins no longer load from a bare C:/...?mtime= path. The server and TUI now import local plugins as file:///C:/... URLs and refresh them by clearing the module cache instead of adding a query string (fix(tui): reload local plugin dependency graphs #47388 and follow-ups).
If you still see this on a current next or beta build, please open a new issue with the server log.
Activity
ransagy commentedon Aug 20, 2026
Same failure on beta-17728, and it hits the TUI too: local plugin files break in the TUI client (
plugins/tui/discovery andcli.jsonpath entries) as well as server-side. A few data points that might help:import("C:/.../x.js")fails even without?mtime=;import("file:///C:/.../x.js?mtime=...")works.?mtime=resolves fine.file://entrypoint).Happy to provide logs or a minimal repro.
github-actions commentedon Oct 20, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
Hona commentedon Oct 20, 2026
This is fixed on
dev. I could not reproduce it on Windows 11 at16c338372a.setup. I tested a standaloneplugins/rtk.ts, a plugin directory with a relative import, a"./relative"entry inopencode.json, and a project.opencode/plugins/plugin.plugins/<dir>/tui.tsdiscovery andcli.json"./relative"entries both load.--singlebuild compiled with Bun 1.4.2, the same version CI uses for releases.C:/...?mtime=path. The server and TUI now import local plugins asfile:///C:/...URLs and refresh them by clearing the module cache instead of adding a query string (fix(tui): reload local plugin dependency graphs #47388 and follow-ups).If you still see this on a current
nextorbetabuild, please open a new issue with the server log.