fix: install failed in deepseek harness desktop #2439

Pre-submission checklist | 提交前检查

• I have searched existing issues and this hasn't been mentioned before | 我已搜索现有问题，确认此问题尚未被提及
• I have read the project documentation and confirmed this issue doesn't already exist | 我已阅读项目文档并确认此问题尚未存在
• This issue is specific to MemOS and not a general software issue | 该问题是针对 MemOS 的，而不是一般软件问题

Bug Description | 问题描述

✓ Lockfile passes supply-chain policies (verified 11h ago)
Progress: resolved 1, reused 0, downloaded 0, added 0
[WARN] 3 deprecated subdependencies found: boolean@3.2.0, ini@1.3.0, prebuild-install@7.1.3
[WARN] Issues with peer dependencies found. Run "pnpm peers check" to list them.

dependencies:

• @memtensor/memos-local-plugin ^2.0.20

Packages: -51

Progress: resolved 154, reused 51, downloaded 0, added 0, done
node_modules/protobufjs postinstall$ node scripts/postinstall
node_modules/onnxruntime-node postinstall$ node ./script/install
node_modules/esbuild postinstall$ node install.js
node_modules/sharp install$ node install/check.js || npm run build
node_modules/better-sqlite3 install$ prebuild-install || node-gyp rebuild --release
node_modules/protobufjs postinstall: Done
node_modules/sharp install: Done
node_modules/better-sqlite3 install: (node:259528) [DEP0176] DeprecationWarning: fs.R_OK is deprecated, use fs.constants.R_OK instead
node_modules/better-sqlite3 install: (Use DeepSeek Harness --trace-deprecation ... to show where the warning was created)
node_modules/onnxruntime-node postinstall: Done
node_modules/esbuild postinstall: Done
node_modules/better-sqlite3 install: prebuild-install warn install No prebuilt binaries found (target=24.18.1 runtime=node arch=x64 libc= platform=win32)
node_modules/better-sqlite3 install: C:\Users\Administrator.dsh\profiles\desktop\node_modules\better-sqlite3>if not defined npm_config_node_gyp (node "D:\AI\DeepSeek-Harness\resources\runtime\pnpm\dist\node-gyp-bin\..\node_modules\node-gyp\bin\node-gyp.js" rebuild --release ) else (node "D:\AI\DeepSeek-Harness\resources\runtime\pnpm\dist\node_modules\node-gyp\bin\node-gyp.js" rebuild --release )
node_modules/better-sqlite3 install: gyp info it worked if it ends with ok
node_modules/better-sqlite3 install: gyp info using node-gyp@12.4.0
node_modules/better-sqlite3 install: gyp info using node@24.18.1 | win32 | x64
node_modules/better-sqlite3 install: gyp info find Python using Python version 3.12.5 found at "D:\DevKit\Python\Python312\python.exe"
node_modules/better-sqlite3 install: gyp info find VS using VS2022 (17.14.37531.7) found at:
node_modules/better-sqlite3 install: gyp info find VS "C:\Program Files\Microsoft Visual Studio\2022\Community"
node_modules/better-sqlite3 install: gyp info find VS run with --verbose for detailed information
node_modules/better-sqlite3 install: gyp info spawn D:\DevKit\Python\Python312\python.exe
node_modules/better-sqlite3 install: gyp info spawn args [
node_modules/better-sqlite3 install: gyp info spawn args 'D:\AI\DeepSeek-Harness\resources\runtime\pnpm\dist\node_modules\node-gyp\gyp\gyp_main.py',
node_modules/better-sqlite3 install: gyp info spawn args 'binding.gyp',
node_modules/better-sqlite3 install: gyp info spawn args '-f',
node_modules/better-sqlite3 install: gyp info spawn args 'msvs',
node_modules/better-sqlite3 install: gyp info spawn args '-I',
node_modules/better-sqlite3 install: gyp info spawn args 'C:\Users\Administrator\.dsh\profiles\desktop\node_modules\better-sqlite3\build\config.gypi',
node_modules/better-sqlite3 install: gyp info spawn args '-I',
node_modules/better-sqlite3 install: gyp info spawn args 'D:\AI\DeepSeek-Harness\resources\runtime\pnpm\dist\node_modules\node-gyp\addon.gypi',
node_modules/better-sqlite3 install: gyp info spawn args '-I',
node_modules/better-sqlite3 install: gyp info spawn args 'C:\Users\Administrator\AppData\Local\node-gyp\Cache\24.18.1\include\node\common.gypi',
node_modules/better-sqlite3 install: gyp info spawn args '-Dlibrary=shared_library',
node_modules/better-sqlite3 install: gyp info spawn args '-Dvisibility=default',
node_modules/better-sqlite3 install: gyp info spawn args '-Dnode_root_dir=C:\Users\Administrator\AppData\Local\node-gyp\Cache\24.18.1',
node_modules/better-sqlite3 install: gyp info spawn args '-Dnode_gyp_dir=D:\AI\DeepSeek-Harness\resources\runtime\pnpm\dist\node_modules\node-gyp',
node_modules/better-sqlite3 install: gyp info spawn args '-Dnode_lib_file=C:\\Users\\Administrator\\AppData\\Local\\node-gyp\\Cache\\24.18.1\\<(target_arch)\\node.lib',
node_modules/better-sqlite3 install: gyp info spawn args '-Dmodule_root_dir=C:\Users\Administrator\.dsh\profiles\desktop\node_modules\better-sqlite3',
node_modules/better-sqlite3 install: gyp info spawn args '-Dnode_engine=v8',
node_modules/better-sqlite3 install: gyp info spawn args '--depth=.',
node_modules/better-sqlite3 install: gyp info spawn args '--no-parallel',
node_modules/better-sqlite3 install: gyp info spawn args '--generator-output',
node_modules/better-sqlite3 install: gyp info spawn args 'C:\Users\Administrator\.dsh\profiles\desktop\node_modules\better-sqlite3\build',
node_modules/better-sqlite3 install: gyp info spawn args '-Goutput_dir=.'
node_modules/better-sqlite3 install: gyp info spawn args ]
node_modules/better-sqlite3 install: gyp: name 'enable_thin_lto' is not defined while evaluating condition 'enable_thin_lto=="true"' in binding.gyp while trying to load binding.gyp
node_modules/better-sqlite3 install: gyp ERR! configure error
node_modules/better-sqlite3 install: gyp ERR! stack Error: gyp failed with exit code: 1
node_modules/better-sqlite3 install: gyp ERR! stack at ChildProcess. (D:\AI\DeepSeek-Harness\resources\runtime\pnpm\dist\node_modules\node-gyp\lib\configure.js:317:18)
node_modules/better-sqlite3 install: gyp ERR! stack at ChildProcess.emit (node:events:509:28)
node_modules/better-sqlite3 install: gyp ERR! stack at ChildProcess._handle.onexit (node:internal/child_process:295:12)
node_modules/better-sqlite3 install: gyp ERR! System Windows_NT 10.0.26200
node_modules/better-sqlite3 install: gyp ERR! command "D:\AI\DeepSeek-Harness\DeepSeek Harness.exe" "D:\AI\DeepSeek-Harness\resources\runtime\pnpm\dist\node_modules\node-gyp\bin\node-gyp.js" "rebuild" "--release"
node_modules/better-sqlite3 install: gyp ERR! cwd C:\Users\Administrator.dsh\profiles\desktop\node_modules\better-sqlite3
node_modules/better-sqlite3 install: gyp ERR! node -v v24.18.1
node_modules/better-sqlite3 install: gyp ERR! node-gyp -v v12.4.0
node_modules/better-sqlite3 install: gyp ERR! $npm_package_name better-sqlite3
node_modules/better-sqlite3 install: gyp ERR! $npm_package_version 12.11.1
node_modules/better-sqlite3 install: gyp ERR! not ok
node_modules/better-sqlite3 install: Failed
[ELIFECYCLE] Command failed with exit code 1.

How to Reproduce | 如何重现

Environment | 环境信息

deepseek harness desktop：V0.2.0-rc.2

Additional Context | 其他信息

No response

Willingness to Implement | 实现意愿

• I'm willing to implement this myself | 我愿意自己解决
• I would like someone else to implement this | 我希望其他人来解决

Root cause analysis (appended after triage)

TL;DR — This is not a bug in MemOS's own code. It happens in the native-dependency build path of @memtensor/memos-local-plugin when that build runs inside the DeepSeek Harness Electron runtime: better-sqlite3 finds no prebuilt binary, falls back to a source build, and node-gyp then aborts because the gyp config it generates carries Electron's build variables — which have no enable_thin_lto key — while Node 24.18.1's common.gypi unconditionally reads that variable on Windows. There is a second, independent blocker behind it (ABI 137 vs 149), so silencing the gyp error alone is not enough.

Environment (measured on the reporting machine, read-only)

Step 1 — no prebuilt binary is found

better-sqlite3's install script is prebuild-install || node-gyp rebuild --release. prebuild-install@7.1.3 defaults to runtime = 'node' and target = process.versions.node (24.18.1), then asks node-abi for the ABI. node-abi@3.96.0 short-circuits:

if (runtime === 'node') {
  if (!target) return process.versions.modules
  if (target === process.versions.node) return process.versions.modules
}

Inside the Electron process this returns 149 (Electron's ABI) instead of Node 24's 137, so it requests an asset named ...-node-v149-win32-x64, which cannot exist → No prebuilt binaries found (target=24.18.1 runtime=node arch=x64 libc= platform=win32). This cannot be worked around with flags as long as the runtime is Electron: prebuild-install recomputes the ABI unconditionally, and every target equal to process.versions.node resolves to Electron's ABI.

Step 2 — the source build fails (the reported error)

node-gyp 12.4.0 then runs in that same Electron process. It downloads the Node 24.18.1 headers and passes -I ...\include\node\common.gypi, but since neither --nodedir nor --dist-url is set, create-config-gypi.js falls back to process.config, so the generated build/config.gypi contains Electron's build variables:

Node 24.18.1's common.gypi (Windows branch, evaluated while the file is loaded) contains both LTO conditions:

['enable_lto=="true"', { ... }],
['enable_thin_lto=="true"', { ... }],

gyp requires any variable used in a condition to be defined; an undefined variable is a hard error, not false:

gyp: name 'enable_thin_lto' is not defined while evaluating condition
'enable_thin_lto=="true"' in binding.gyp while trying to load binding.gyp

The in binding.gyp part is only gyp's attribution to the build file being loaded — the condition itself lives in Node's common.gypi, which every binding.gyp pulls in via -I. better-sqlite3's own binding.gyp contains no thin_lto reference (verified), so there is nothing to patch there either.

This is invisible in normal Node usage for two reasons: a real Node binary's process.config.variables does define enable_thin_lto, and when --nodedir/--dist-url is passed node-gyp reads the headers' config.gypi, which also defines it. Related upstream report on the same variable, in a different failure mode (thin-LTO flags leaking into an MSVC project, not an undefined variable): nodejs/node#64674. The same failure shape applies to any node-gyp-built native dependency installed through DSH desktop, not just this one.

Step 3 — even a successful compile would not load

better-sqlite3 is a V8-ABI addon (NODE_MODULE_INIT, so it registers as node_register_module_v137 with these headers), while the DSH host process requires ABI 149. If gyp were fixed without changing the headers, require('better-sqlite3') would still fail with the usual "compiled against a different Node.js version" error. Only a build against the Electron 44 headers can load in this host.

Result on disk

pnpm exits with [ELIFECYCLE] Command failed with exit code 1 and rolls the install back: the profile package.json and pnpm-lock.yaml have no @memtensor entry, while leftovers remain (empty node_modules/@memtensor/, half-written node_modules/better-sqlite3/build/config.gypi). An earlier attempt of the same install stopped one step before this, at [ERR_PNPM_IGNORED_BUILDS] — pnpm does not run dependency build scripts until they are approved, and approving them is what exposes this failure.

Possible directions (not validated end-to-end here)

Plugin / package side:

• Do not depend on compiling a V8-ABI addon on the client: ship prebuilt binaries per platform/ABI (Electron 44 → ABI 149), or make the prebuild lookup runtime-aware.
• Or switch the local storage layer to something ABI-stable: a Node-API module, or node:sqlite — the DSH Electron 44 runtime embeds Node 24.18.1 with SQLite (process.versions.sqlite = 3.53.1).

Client / install side (the actual fix for DSH desktop):

• Install profile dependencies with Electron headers, i.e. electron-rebuild semantics: npm_config_runtime=electron, npm_config_target=44.0.0, npm_config_disturl=https://electronjs.org/headers. node-gyp then reads the Electron headers' config.gypi (which defines enable_thin_lto) and produces ABI-149 binaries.

Minimal unblock for the gyp error only (does not fix the ABI mismatch):

• Set npm_config_nodedir=<node-gyp cache>\24.18.1 or npm_config_disturl=https://nodejs.org/download/release/, so create-config-gypi.js reads the Node headers' config.gypi, which has enable_thin_lto: "false".

How this was determined

Read-only inspection on the reporting machine, without modifying the plugin: the DSH profile (package.json, pnpm-lock.yaml, .plugin-manager/logs/operation-*/pnpm.log), the installed better-sqlite3/binding.gyp and generated build/config.gypi, prebuild-install/rc.js, node-abi/index.js, node-gyp's create-config-gypi.js, and Node 24.18.1's cached common.gypi / config.gypi; plus running ELECTRON_RUN_AS_NODE=1 "DeepSeek Harness.exe" -e "..." to print process.versions and process.config.variables — which reports enable_lto: true and confirms the enable_thin_lto key is absent.

Related issues and an upstream fix (update)

Duplicate check

Searched this repo and GitHub-wide for the error in this report — there is no exact duplicate: this is currently the only issue carrying enable_thin_lto is not defined / ELIFECYCLE for a DSH desktop plugin install. What exists instead is a recurring family of better-sqlite3 native-module reports, all from other clients or other Node majors, and all closed:

Upstream, only nodejs/node#64674 mentions the same gyp variable — a different failure mode (thin-LTO flags leaking into an MSVC project → LNK1117, not an undefined variable); closed 2026-07-22.

Cleaner fix for the gyp error: node-gyp >= 13.0.0

nodejs/node-gyp#3331 ("fix: disable LTO for addon builds on Windows", merged 2026-06-10, first released in v13.0.0 on 2026-06-12) added this to lib/create-config-gypi.js:

// disable LTO for addon builds. node release builds may enable (thin) LTO,
variables.enable_lto = 'false'
variables.enable_thin_lto = 'false'

With node-gyp >= 13.0.0 the generated build/config.gypi therefore always defines enable_thin_lto, and the failure reported here cannot occur. DSH desktop bundles node-gyp 12.4.0 (released 2026-06-05), whose create-config-gypi.js contains no such lines — it misses the fix by seven days. Upgrading the bundled node-gyp to >= 13 is thus the most direct client-side remedy, and it supersedes the npm_config_nodedir / npm_config_disturl workaround suggested above. Neither of them fixes the ABI mismatch in Step 3, which still requires Electron headers.