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

[karlbateman]

I'm seeing the same issue on MacOS

[bubbis-poncho]

I can reproduce the same startup/debug hang on Linux.

Environment

• OS: Linux
• OpenCode: 1.18.10
• Plugin: @morphllm/opencode-morph-plugin@2.0.16
• MORPH_API_KEY: unset

Reproduction

With the plugin registered in the global config:

timeout 20s opencode debug config --print-logs

The command hangs after the initial config-loading messages and must be terminated.

For comparison, both of these complete successfully:
MORPH_API_KEY=placeholder opencode debug config --print-logs
OPENCODE_PURE=1 opencode debug config --print-logs

With a key present, the plugin logs that it loaded normally. This suggests the hang occurs specifically when plugin initialization attempts to read morph.apiKey through client.config.get().

Expected behavior

OpenCode should start and debug commands should complete even when MORPH_API_KEY is not configured. The plugin should log a warning and disable Morph functionality rather than block startup.

##Suggested fix
Avoid awaiting client.config.get() during plugin initialization. The API key could be read through the plugin config hook instead. If the config lookup is required, it should have a bounded timeout and fail open.

[Erudition]

Same issue here on Gnu/Linux. The README suggests you can place the env var directly in opencode.json, which I did, so the local env var should definitely not be required. Even if it were required, OpenCode should not hang, so this may be a major bug in upstream OpenCode...

If this fixes it for OP, we should remove the Windows-specific title, it's cross platform.