[Bug]: Nightly fails to launch on Windows Server 2025: Cannot find native binding

[Porkstone]

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Summary

The T3 Code nightly desktop app fails to launch on Windows Server 2025. An Electron error dialog reports "A JavaScript error occurred in the main process" and an uncaught "Cannot find native binding" exception.

Steps to reproduce

1. Install T3 Code nightly 0.0.41-nightly.20260908.1400 on Windows Server 2025.
2. Launch the installed desktop app.
3. Observe the main-process JavaScript error dialog; the app cannot be used.

Expected behavior

The desktop app launches successfully and displays its normal interface.

Actual behavior

Startup fails with an uncaught native-binding exception. The dialog includes generic advice to run npm i after removing package-lock.json and node_modules, although this is an installed desktop build.

Impact

Blocks work completely: unable to launch the desktop app.

Version or commit

0.0.41-nightly.20260908.1400 (read from the installed executable's file version; product name: T3 Code (Nightly)).

Environment

• Microsoft Windows Server 2025 Standard Evaluation
• OS version: 10.0.26100
• OS architecture: 64-bit
• Installed desktop application under %LOCALAPPDATA%\Programs\t3code

Logs or stack traces

Transcribed from the error screenshot. Two long file paths are truncated by the dialog; ... below marks those truncations. The underlying native package name is not visible, so the failing dependency and root cause are not yet confirmed.

A JavaScript error occurred in the main process

Uncaught Exception:
Error: Cannot find native binding. npm has a bug related to optional dependencies
(https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both
package-lock.json and node_modules directory.
    at Object.<anonymous>
    (C:\Users\Administrator\AppData\Local\Programs\t3code\resources\app.asar\node_mo...:11)
    at Module._compile (node:internal/modules/cjs/loader:1880:14)
    at Object.js (node:internal/modules/cjs/loader:2013:10)
    at Module.load (node:internal/modules/cjs/loader:1601:32)
    at node:internal/modules/cjs/loader:1403:12
    at c._load (node:electron/js2c/node_init:2:18159)
    at Module.load (node:internal/modules/cjs/loader:262:19)
    at Module.require (node:internal/modules/cjs/loader:1624:12)
    at require (node:internal/modules/helpers:153:16)
    at Module.<anonymous>
    (C:\Users\Administrator\AppData\Local\Programs\t3code\resources\app.asar\apps\des...:24)

Related reports

#3125 reports an earlier missing native binding in a nightly backend. #8201 concerns Windows application-control blocking native addons. These may help investigation, but this screenshot shows a main-process startup exception and does not establish either underlying cause.

Workaround

None confirmed.

[juliusmarminge]

Triage

This looks like a real desktop launch blocker, not a duplicate of #3125 or #8201.

The dialog is an Electron main-process crash. The wording is the generic NAPI-RS loader error (Cannot find native binding / npm optional-deps note). In current loaders that string is a wrapper: the real failure (missing file, ERR_DLOPEN_FAILED, Code Integrity, missing VC++ runtime) is on error.cause, which the dialog does not show.

Likely cause

@napi-rs/keyring is imported at module load from apps/desktop/src/preview/BrowserImport/ChromiumKeys.ts, and that file is on the main-process startup graph (main.ts → BrowserImport → ChromiumCookies). The binding is only used for macOS Chromium cookie import. Windows import uses DPAPI and should never need it.

That matches the truncated stack (app.asar\node_modules\... then app.asar\apps\desktop\...) and the fact that this is an installed build, not a source tree where npm i would help.

Windows Server 2025 Evaluation is a plausible place for the .node to be present but unloadable: WDAC / Code Integrity, or a clean image without the VC++ 2015–2022 redistributable. Packaging already stages keyring.win32-*-msvc.node (stageKeyringNativeBinaries in scripts/build-desktop-artifact.ts).

Same-day window-capture work (#8103, @crowecawcaw/xa11y) is unlikely here: that native is loaded in a worker on first capture, and the desktop code is written so a missing xa11y binding does not take down main-process startup.

Not the same bug as

Issue	Why it is different
#3125	Backend missing @yuuang/ffi-rs-*; process running, no window, crash-loop
#8201 / #8373	App Control blocks unsigned ffi-rs / passkeys in *.asar.unpacked; backend crash-loop or HTTP 500, not this main-process dialog

Those are still useful: if launch is fixed and the backend then dies, look there.

Fix already in flight

#10667 defers the keyring import until a macOS cookie import actually needs it, and turns a failed load into keychainUnavailable instead of an uncaught exception. It was observed on Windows 0.0.40 + a later nightly with Code Integrity event 3077 on keyring.win32-x64-msvc.node. Nightly 0.0.41-nightly.20260908.1400 does not include that PR.

Signing remaining Windows natives is a separate track (#8206, aimed at #8201).

Please confirm (optional but useful)

1. The two truncated paths in the dialog — especially whether node_modules is @napi-rs\keyring\index.js.
2. Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational for event 3077 around launch (blocked .node path).
3. Whether the VC++ 2015–2022 x64 redistributable is installed.
4. Whether the installed nightly is x64 or ARM64 (the report only says 64-bit).

Possible local check: install the VC++ x64 redist and relaunch. That only helps if the addon is present and not blocked by App Control.

Next step for maintainers: review/merge #10667 so Windows startup no longer loads a macOS-only native.

[Porkstone]

Confirmed on the affected Windows Server 2025 machine: the installed x64 nightly's native modules could not resolve VCRUNTIME140.dll. The .node files themselves were present.

For 0.0.41-nightly.20260908.1400 (packaged commit eb115063634c), loading @napi-rs/keyring with the normal Windows machine/user PATH exposed this underlying error:

@napi-rs/keyring/index.js:500:11
Error: Cannot find native binding ...
  cause: Error: The specified module could not be found.
  ...app.asar.unpacked\node_modules\@napi-rs\keyring\keyring.win32-x64-msvc.node
  code: ERR_DLOPEN_FAILED

The binary's PE import table includes VCRUNTIME140.dll, which was absent from the normal system/app DLL search locations. The NAPI-RS wrapper hides this missing dependent DLL behind generic npm optional-dependency advice; reinstalling npm dependencies is not the remedy for this installed desktop build.

A controlled test confirmed the dependency:

Dependency	Normal Windows PATH	Same PATH + temporary folder containing only VCRUNTIME140.dll
@napi-rs/keyring	Fails	Loads
@clerk/electron-passkeys	Fails	Loads
@crowecawcaw/xa11y	Fails	Loads

This also explains why initial agent-launched tests passed while Explorer launches failed: Codex adds bundled runtime directories to its environment's PATH, supplying that DLL and masking the missing system prerequisite.

Installed the Microsoft-signed Visual C++ v14 x64 Redistributable 14.51.36247.0 from Microsoft's official download. Installation returned exit code 0, installed the DLL under System32, and all three native modules then loaded successfully with the normal Windows PATH, without the temporary workaround. A subsequent full Explorer launch has not yet been verified in this investigation.

The eager keyring import described in triage explains why this becomes a main-process startup failure. Deferring that macOS-only import addresses the startup fragility, but the Windows packaging/installer should also ensure the required VC++ runtime is available for the other native features.

[juliusmarminge]

Fixed by #10667 (merged to main) — defers @napi-rs/keyring until macOS cookie import so Windows startup no longer loads that native at module init.

Separate follow-ups remain for VC++ redistributable packaging / other unsigned natives (#8206 / #8201); those are not this startup path.