[Bug] v2.22.0 Intel Mac: fail-fast reports onnxruntime binding missing though file exists and loads under Node/Bun

[tlerbao]

Summary

On an Intel Mac, opencode-mem@2.22.0 still reports that the pinned onnxruntime-node binding is missing when invoked through OpenCode, even though the exact file exists and both Node and Bun can load it successfully outside the plugin tool call.

This appears different from #158 and #184: in those reports the x64 artifact was actually absent. Here the direct onnxruntime-node@1.22.0 artifact is present and loadable after a clean plugin-cache reinstall.

Environment

• macOS 13.3, Intel x86_64 (darwin/x64)
• OpenCode 1.18.9
• Bun 1.3.14
• Node.js v22.19.0
• opencode-mem 2.22.0
• Local embedding model: Xenova/nomic-embed-text-v1

Steps to reproduce

1. Configure the plugin as opencode-mem@2.22.0.

2. Completely exit OpenCode.

3. Remove only the plugin caches:

   rm -rf ~/.cache/opencode/packages/opencode-mem ~/.cache/opencode/packages/opencode-mem@latest ~/.cache/opencode/packages/opencode-mem@2.22.0

4. Start OpenCode and allow it to reinstall the plugin.

5. Completely exit and start OpenCode again after installation is complete.

6. Invoke the memory tool in add or search mode.

Actual behavior

Both add and search fail with:

Local embedding native binding missing for darwin/x64 at ~/.cache/opencode/packages/opencode-mem@2.22.0/node_modules/onnxruntime-node/bin/napi-v6/darwin/x64/onnxruntime_binding.node. On Intel Mac (darwin/x64), onnxruntime-node@1.24+ ships without an x64 binding; opencode-mem pins 1.22.0. If this persists after updating, clear OpenCode's plugin cache (~/.cache/opencode/packages/opencode-mem@*) and reinstall, or configure remote embeddings via embeddingApiUrl + embeddingApiKey.

The old OpenCode serve --service process was also explicitly terminated before repeating the test in a new OpenCode conversation, with the same result.

Binding verification

The exact path reported as missing exists:

onnxruntime-node version: 1.22.0
binding size: 226664 bytes
file type: Mach-O 64-bit bundle x86_64
permissions: 0644

From the freshly installed plugin directory, all of the following succeed under both Node and Bun:

require.resolve("onnxruntime-node")
require("onnxruntime-node")
prepareOnnxruntimeForTransformers()

They resolve to the direct package at:

node_modules/onnxruntime-node/dist/index.js

The plugin's standalone prepareOnnxruntimeForTransformers() check succeeds, but the same OpenCode process reports the binding as missing when the registered memory tool initializes embeddings.

Expected behavior

The local embedding model should initialize using the bundled direct onnxruntime-node@1.22.0 x64 binding, and memory add/search should work.

Related

• Intel Mac (darwin/x64): onnxruntime-node missing native binary — embedding init fails, memory stuck initializing #158
• [Bug] Intel Mac still broken on v2.20.0: onnxruntime override is ignored in OpenCode's nested install #184
• fix(embedding): pin onnxruntime-node for Intel Mac nested installs #198

PR #198 added the direct dependency, resolver shim, and fail-fast check. Its Intel Mac real-device test-plan items appear to have remained unchecked, so this may be an OpenCode plugin-runtime path or initialization-context difference that is not covered by the standalone resolver tests.

[EyJunge1]

Thanks for the detailed report. The fix from #211 has been merged and passed the nested-install embedding test on a real GitHub Actions Intel Mac runner using Bun 1.3.14 and Node 22.

Once the next release is available, could you please clear the OpenCode plugin cache, reinstall the plugin, and verify both memory add and memory search again?

If the problem persists, please comment here with the new error message. The fix now preserves the underlying ONNX load error instead of incorrectly reporting the existing pinned binding as missing.

[tlerbao]

Retested after upgrading to opencode-mem@2.22.1 with a clean plugin install. Both memory add and memory search still fail, but the error has changed as expected after #211:

{"success":false,"error":"ResolveMessage: Cannot find module '@huggingface/transformers' from ''"}

Environment remains:

• macOS 13.3 Intel x64
• OpenCode 1.18.9
• Bun 1.3.14
• Node.js v22.19.0
• opencode-mem 2.22.1

I verified that this is not an incomplete package installation:

• node_modules/@huggingface/transformers exists and is version 4.2.0.
• The direct onnxruntime-node@1.22.0 x64 binding exists.
• From the plugin tree, require.resolve("@huggingface/transformers") succeeds under Node and Bun.
• A bare require("@huggingface/transformers") fails because it reaches the nested onnxruntime-node@1.24.3, which has no darwin/x64 binding.
• Calling prepareOnnxruntimeForTransformers() and then loading with a createRequire() anchored to the absolute dist/services/embedding.js path succeeds.

The production tool path returns from '', so the referrer used by requireFromHere appears to be empty inside the OpenCode plugin host. This may explain why the nested fixture passes while the live plugin does not: the fixture anchors createRequire to an explicit absolute filename, whereas production initializes it from import.meta.url.

There were no stale OpenCode/service processes during this 2.22.1 test. Please let me know if you want a diagnostic build that logs import.meta.url and the resolved require filename from the live tool path.

[EyJunge1]

Thanks again for the detailed follow-up. A second fix has now been released in opencode-mem@2.22.2.

The new error (Cannot find module '@huggingface/transformers' from '') was caused by OpenCode's compiled Bun host resolving Transformers after the ONNX CommonJS resolver shim was installed. The fix now resolves Transformers to an absolute path first, then installs the ONNX pin shim. We also added an OpenCode-shaped Bun --compile regression fixture, which passes on the Intel macOS runner with Bun 1.3.14 and Node 22.

Could you please:

1. Fully exit OpenCode and terminate any remaining OpenCode service processes.
2. Clear the plugin cache for opencode-mem.
3. Install/update to opencode-mem@2.22.2.
4. Start OpenCode again and test both memory add and memory search.

Please let us know whether both operations now work. If either still fails, please include the new exact error message.