Intel (x64) macOS 1.7.5: recording crashes — onnxruntime-node darwin/x64 binding missing (Cannot find module onnxruntime_binding.node)

[joost-ai]

Describe the bug

On the Intel (x64) macOS build of 1.7.5, starting a recording (meeting or note) crashes the moment speaker identification runs, with:

Cannot find module '../bin/napi-v6/darwin/x64/onnxruntime_binding.node'
Require stack:
- .../app.asar/node_modules/onnxruntime-node/dist/binding.js
- .../app.asar/node_modules/onnxruntime-node/dist/backend.js
- .../app.asar/node_modules/onnxruntime-node/dist/index.js
- .../app.asar/src/helpers/liveSpeakerIdentifier.js
- .../app.asar/src/helpers/ipcHandlers.js
- .../app.asar/main.js

Root cause (two independent defects, both specific to the x64 mac build)

1. onnxruntime-node 1.27.0 ships no darwin/x64 binary. Microsoft dropped the Intel-macOS ONNX Runtime prebuilt after 1.23. Verified against the npm tarballs:

onnxruntime-node	bundles darwin/x64/onnxruntime_binding.node?
1.27.0 (shipped in 1.7.5)	❌
1.26.0	❌ (arm64 only)
1.24.0 / 1.25.0	❌
1.23.0	✅ (last version with it)
1.22.0	✅

So on Intel Macs, require('../bin/napi-v6/darwin/x64/onnxruntime_binding.node') resolves to a path that cannot exist for this dependency version → hard, uncaught crash.

2. The x64 build's app.asar.unpacked native-binary tree is empty. Independently of #1, the asar header marks the onnxruntime binaries as unpacked, but the build never copied them to disk. asar extract fails with ENOENT for every platform's binary:

$ find "OpenWhispr.app/Contents/Resources/app.asar.unpacked/node_modules/onnxruntime-node/bin" -type f | wc -l
0
# asar extract app.asar ... -> ENOENT for darwin/arm64, linux/{arm64,x64}, win32/{arm64,x64}

So even where a binary exists in the package (e.g. arm64), this build's asar would be unable to load it. (Only the x64 build was inspected; the arm64 build is a separate artifact and may be fine.)

Why it also crashes on a plain "note"

The crash is the speaker-ID path (liveSpeakerIdentifier.js:373 / :478), which require("onnxruntime-node") with no try/catch. isAvailable() only checks whether the VAD/embedding models are downloaded — it never checks whether the native binding can actually load. The note text-embedding path (_asyncVectorUpsert → localEmbeddings) is gated by vectorIndex.isReady() and wraps errors in .catch(()=>{}), so that one fails silently; the speaker-ID require is what surfaces the fatal dialog.

Environment

• OpenWhispr 1.7.5 (Intel .dmg), app binary x86_64 (com.gizmolabs.openwhispr, Developer ID, hardened runtime)
• Intel Core i7-9750H, macOS (Darwin 25.5.0)
• onnxruntime-node 1.27.0, napi-v6

Steps to reproduce

1. Install the Intel OpenWhispr-1.7.5.dmg on any Intel Mac.
2. Start a meeting/note recording with speaker identification enabled.
3. Crash with the error above.

Suggested fixes

1. Make the onnxruntime dependency load-tolerant (highest value): wrap the require("onnxruntime-node") sites (liveSpeakerIdentifier, onnxWorker) so a missing/unloadable binding degrades to whisper-only transcription instead of an uncaught crash, and have isAvailable() actually probe that the binding loads.
2. For the Intel-mac target specifically, either pin onnxruntime-node to ≤1.23.x (last release with a darwin/x64 binary) for that build, or officially drop Intel-mac speaker-ID and reflect it in the UI/download page.
3. Audit the x64 mac CI packaging step — the asarUnpack glob marks the native binaries unpacked but none are copied into app.asar.unpacked (empty tree above).

Workaround for affected users

Disable Speaker Identification / diarization in Settings — recording then works (transcription is unaffected; speaker-ID can't run on Intel Macs in this build regardless).

Related

• ONNX worker crash-loops on Linux tar.gz: ERR_MODULE_NOT_FOUND for onnxWorker.js inside app.asar #968 (onnx worker path resolution on Linux tar.gz) — same subsystem, different platform/mechanism.
• Transcription Fails - "Symbol not found" #862 references a separate onnx artifact (Contents/Resources/bin/libonnxruntime.1.23.2.dylib, the sherpa/Parakeet path), not the onnxruntime-node npm binding.