Windows: compiled OMP fails to load plugins resolving @oh-my-pi/pi-* from B:\~BUN\root

[gabrielmoreira]

Description

On Windows native, OMP itself starts, but installed/enabled plugins do not become available. No plugin-provided tools or commands appear after startup, reload, enable/disable, or reinstall/update.

The plugins are installed and omp plugin doctor reports them as OK, but extension initialization fails at runtime because OMP tries to resolve internal @oh-my-pi/pi-* packages from Bun's compiled runtime root:

B:\~BUN\root

The failure appears to happen before plugin tools/commands can be registered.

This looks specific to the compiled Windows executable / Bun runtime module resolution path, not to missing plugin installs.

Possibly related to #1215, but this report covers Windows native with multiple common plugins failing after update/reinstall.

---

Steps to Reproduce

Existing environment repro

1. Install OMP on Windows native.
2. Install/update these plugins:

omp plugin install @juicesharp/rpiv-ask-user-question@latest
omp plugin install @oh-my-pi/swarm-extension@latest
omp plugin install @plannotator/pi-extension@latest
omp plugin install @runfusion/fusion@latest
omp plugin install pi-autoresearch@latest

3. Verify plugin state:

omp plugin list --json
omp plugin doctor --json

4. Start OMP.
5. Try reloading or toggling plugins:

/reload-plugins

or disable/re-enable plugins from the UI/CLI.

6. Observe that no plugin-provided tools/commands appear.
7. Check the OMP log:

%USERPROFILE%\.omp\logs\omp.<date>.log

Minimal fresh-environment repro idea

On a clean Windows native machine/profile:

omp --version
bun --version

omp plugin install @juicesharp/rpiv-ask-user-question@latest
omp plugin install @oh-my-pi/swarm-extension@latest
omp plugin install @plannotator/pi-extension@latest
omp plugin install @runfusion/fusion@latest

omp plugin list --json
omp plugin doctor --json

omp

Then check whether plugin-provided tools/commands are registered. If they are not, inspect:

%USERPROFILE%\.omp\logs\omp.<date>.log

for Failed to load extension errors resolving @oh-my-pi/pi-* from B:\~BUN\root.

---

Expected Behavior

Enabled plugins should load successfully.

Plugin-provided tools, commands, UI components, or extension behavior should be available after OMP startup or after /reload-plugins.

Plugins should be able to import OMP internal packages such as:

@oh-my-pi/pi-tui
@oh-my-pi/pi-coding-agent
@oh-my-pi/pi-agent-core

without failing module resolution from Bun's compiled runtime root.

---

Error Output

Failed to load extension
path="C:\Users\<user>\.omp\plugins\node_modules\@juicesharp\rpiv-ask-user-question\index.ts"
error="Failed to load extension: ResolveMessage: Cannot find module '@oh-my-pi/pi-tui' from 'B:\~BUN\root'"

Failed to load extension
path="C:\Users\<user>\.omp\plugins\node_modules\@oh-my-pi\swarm-extension\src\extension.ts"
error="Failed to load extension: ResolveMessage: Cannot find module '@oh-my-pi/pi-coding-agent' from 'B:\~BUN\root'"

Failed to load extension
path="C:\Users\<user>\.omp\plugins\node_modules\@plannotator\pi-extension\index.ts"
error="Failed to load extension: ResolveMessage: Cannot find module '@oh-my-pi/pi-agent-core' from 'B:\~BUN\root'"

Failed to load extension
path="C:\Users\<user>\.omp\plugins\node_modules\@runfusion\fusion\dist\extension.js"
error="Failed to load extension: ResolveMessage: Cannot find module '@oh-my-pi/pi-coding-agent' from 'B:\~BUN\root'"

After updating to the latest available plugin versions, the same errors still occur.

---

Platform

Windows (native)

---

omp version

omp/15.1.8

---

Bun version

1.3.14

---

Provider

Other

This does not appear provider-specific. The failure happens during plugin/extension initialization before plugin capabilities are available.

---

Area

Extensions / Plugins

---

Additional context

Installed plugin state after update

omp plugin list --json reports the plugins installed and enabled:

{
  "npm": [
    {
      "name": "@juicesharp/rpiv-ask-user-question",
      "version": "1.12.0",
      "enabled": true
    },
    {
      "name": "@oh-my-pi/swarm-extension",
      "version": "13.17.0",
      "enabled": true
    },
    {
      "name": "@plannotator/pi-extension",
      "version": "0.19.21",
      "enabled": true
    },
    {
      "name": "@runfusion/fusion",
      "version": "0.32.0",
      "enabled": true
    },
    {
      "name": "pi-autoresearch",
      "version": "1.4.0",
      "enabled": true
    }
  ],
  "marketplace": []
}

omp plugin doctor --json reports the plugin directory, package manifest, node_modules, and all five plugins as OK.

So the issue does not look like a missing install or broken plugin directory.

Things tried

I tried the following:

1. Updated all installed npm plugins to latest:

omp plugin install @juicesharp/rpiv-ask-user-question@latest
omp plugin install @oh-my-pi/swarm-extension@latest
omp plugin install @plannotator/pi-extension@latest
omp plugin install @runfusion/fusion@latest
omp plugin install pi-autoresearch@latest

2. Restarted OMP.
3. Tried reloading plugins.
4. Tried disabling/re-enabling plugins.
5. Verified plugin install state with:

omp plugin list --json
omp plugin doctor --json

6. Temporarily removed/renamed stale user-level OMP package/launcher paths to rule out a local stale runtime issue, including:

%USERPROFILE%\node_modules\@oh-my-pi\pi-coding-agent
%USERPROFILE%\node_modules\.bin\omp*

That removed an older separate failure mode involving malformed Windows paths, but the active failure remained:

Cannot find module '@oh-my-pi/...' from 'B:\~BUN\root'

Why this seems like an OMP runtime/loader issue

The plugins are present and enabled, but extension loading fails when resolving OMP internal packages from the compiled Bun executable root:

B:\~BUN\root

The affected imports are internal OMP packages used by plugins:

@oh-my-pi/pi-tui
@oh-my-pi/pi-coding-agent
@oh-my-pi/pi-agent-core

The result is that OMP starts, but plugin capabilities never register, so no new plugin tools or commands appear.

Note about pi-autoresearch

pi-autoresearch is installed and enabled, but it does not appear in the same extension-load errors. Its manifest declares:

{
  "pi": {
    "extensions": ["./extensions"],
    "skills": ["./skills"]
  }
}

The installed structure contains:

extensions/pi-autoresearch/index.ts

So it may be resolving to zero extension entrypoints depending on how plugin extension path discovery handles nested extension directories. This may be separate from the B:\~BUN\root import-resolution failure affecting the other four plugins.

[roboomp]

Same root cause as #1215 — the Cannot find module '@oh-my-pi/pi-*' from 'B:\~BUN\root' errors are getResolvedSpecifier calling Bun.resolveSync(spec, import.meta.dir) where import.meta.dir lives inside Bun's compiled-binary virtual FS (/$bunfs/root on POSIX, B:\~BUN\root on Windows), which has no walkable node_modules tree. The throw propagates uncaught and loadExtension drops the plugin.

The Windows path (B:\~BUN\root) just reflects how Bun maps bunfs to a drive letter on Win32; the resolver behavior is identical to POSIX once you account for the path separator. So the four plugins listed (@juicesharp/rpiv-ask-user-question, @oh-my-pi/swarm-extension, @plannotator/pi-extension, @runfusion/fusion) all fail for the same reason as pi-schedule-prompt and pi-provider-kiro in #1215.

Open PR: #1216 — wraps getResolvedSpecifier in try/catch and lets the subsequent rewriteBareImportsForLegacyExtension resolve the bare specifier from the plugin's real ~/.omp/plugins/node_modules/... peer-dep tree on Windows the same way it does on POSIX. No Windows-specific changes needed beyond what's already in that PR.

The pi-autoresearch observation about extensions/pi-autoresearch/index.ts nested under a pi.extensions: ["./extensions"] manifest entry is unrelated to the B:\~BUN\root failure and is a separate extension-discovery question — please open a follow-up issue if it doesn't resolve once #1216 lands, with the exact omp plugin doctor --json output for that plugin and the log line (or its absence) for that extension path.

Closing as duplicate of #1215. Subscribe there for the merge.

[roboomp]

Opened #1368 for the pi-autoresearch directory-of-subdirectories case (the secondary observation in this report). The primary B:\~BUN\root failure for the other four plugins is the same root cause as #1215 and remains tracked in #1216.

[roboomp]

Valid bug at report time (15.1.8) but already fixed in the current tree (15.10.2) via #1216, including the Windows-specific bunfs-root literal fix.

Evidence: Closed as duplicate of #1215 (fixed by #1216). Fix present: rewriteLegacyPiImports/resolveLegacyPiSpecifier fallback (legacy-pi-compat.ts:213-221,596-615); Win32 __computeBunfsPackageRoot derives shim roots from import.meta.dir (legacy-pi-compat.ts:94-103,144-155; CHANGELOG.md:681). Caveat: #1215 @kubetz v15.3.2 recurrence comment not re-triaged—verification recommended.

This looks resolved in main (v15.10.2), so closing during a stale-issue sweep. Please reopen if a specific part is still outstanding.