Windows: enabling @morphllm/opencode-morph-plugin@2.0.16 causes OpenCode 1.17.11 startup/debug/session load to hang

[voarsh2]

On Windows, enabling @morphllm/opencode-morph-plugin in OpenCode causes OpenCode to stall during startup / session load.

This is not just a TUI rendering issue and not just one bad session:

• opencode --pure works
• opencode --pure --mini works
• opencode -s <session> --pure --mini works
• but normal mode with the plugin enabled stalls, including debug commands

Environment

• OS: Windows 11
• OpenCode: 1.17.11
• Plugin: @morphllm/opencode-morph-plugin@2.0.16

Repro

1. Install the plugin in ~/.config/opencode
2. Add it to global opencode.json:

{
  "plugin": ["@morphllm/opencode-morph-plugin"],
  "instructions": [
    "node_modules/@morphllm/opencode-morph-plugin/instructions/morph-tools.md"
  ]
}

3. Run any of the following:

opencode --mini
opencode -s <session_id> --mini
opencode debug config --print-logs --log-level DEBUG
opencode debug info --print-logs --log-level DEBUG

Actual behavior

OpenCode hangs/stalls during init.

What makes this especially suspicious is that even the debug commands stall when the plugin is enabled:

• opencode debug config --print-logs --log-level DEBUG
• opencode debug info --print-logs --log-level DEBUG

With the plugin enabled, the logs only show early bootstrap/config loading and then stop making progress.

Expected behavior

OpenCode should initialize normally, and debug commands should complete normally.

What I ruled out

I spent quite a while isolating this, and these do not appear to be the cause:

• SQLite DB corruption
• broken session data
• OpenCode cache/state/snapshot directories
• repo-specific config
• full TUI only

Important evidence

These work:

opencode --pure
opencode --pure --mini
opencode -s <session_id> --pure --mini

So the same session can load when external plugins are disabled.

That strongly suggests the problem is in the plugin-enabled startup path on Windows.

I also tried disabling all Morph feature flags:

$env:MORPH_COMPACT="false"
$env:MORPH_EDIT="false"
$env:MORPH_WARPGREP="false"
$env:MORPH_WARPGREP_GITHUB="false"

but OpenCode still stalled with the plugin enabled. So this appears to happen before/independent of actual tool usage.

Relevant log pattern

With the plugin enabled, debug commands get through early startup like:

• creating instance
• fromDirectory
• bootstrapping
• loading path="C:\Users\Admin\.config\opencode\config.json"
• loading path="C:\Users\Admin\.config\opencode\opencode.json"
• loading path="C:\Users\Admin\.config\opencode\opencode.jsonc"

and then stop progressing.

Notes

This may be related to Windows-specific plugin init/runtime behavior rather than tool execution itself.

I noticed there was a previous Windows-related issue/PR:

• Plugin fails to load in opencode 1.3.17 on Windows (ESM/CJS interop issues) #10
• Fix Windows plugin loader interop for opencode 1.3.17 #16

This seems like a different failure mode:

• not an obvious load exception
• instead OpenCode hangs/stalls once the plugin is enabled