[Bug]: Smart App Control blocks unsigned @yuuang/ffi-rs native binding on Windows — backend crash-loops, app never opens #8373

Before submitting

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

Area

Build, CI, or release tooling

Steps to reproduce

1. On Windows 11 with Smart App Control ON (enforcement mode), install T3 Code 0.0.35 x64
   from the GitHub release installer.
2. Launch T3 Code.
3. No window appears.
4. Check ~/.t3/userdata/logs/server-child.log — the backend child process fails to load a
   native binding and exits with code=1 roughly every 10 seconds, indefinitely.

Note on reproducing: Smart App Control is only in enforcement mode on clean Windows 11
installs, and it silently disables itself on some machines during evaluation. A machine
where it is Off or in Evaluation mode will NOT reproduce this — evaluation mode is
audit-only and does not block. Check under Windows Security → App & browser control →
Smart App Control.

Expected behavior

The app launches and opens a window.

If a bundled native binding cannot be loaded, that failure is surfaced in the UI — or the
dependent feature degrades — rather than the backend silently crash-looping forever.

Actual behavior

No window ever appears. The backend child process crash-loops roughly every 10 seconds with
nothing shown in the UI. The only way to discover the cause is server-child.log or the
Windows CodeIntegrity event log.

Windows Code Integrity is blocking the bundled native binding:

resources\server.asar.unpacked\node_modules\@yuuang\ffi-rs-win32-x64-msvc\ffi-rs.win32-x64-msvc.node

It ships unsigned. Smart App Control only loads binaries Authenticode-signed with an RSA
certificate from a trusted CA (ECC is not supported:
https://learn.microsoft.com/en-us/windows/apps/develop/smart-app-control/code-signing-for-smart-app-control).

Signing the main executable is not sufficient — every .node binary loaded into the process
is verified independently. Because native addons must sit outside the asar archive to be
dlopen-able, this file lands in server.asar.unpacked as a plain DLL and is checked like any
other binary.

Affected versions (installer sizes):

0.0.29 — 341,129,672 B — works
0.0.33 — 153,172,472 B — works
0.0.34 — 142,157,688 B — untested, same size class as 0.0.35
0.0.35 — 142,152,024 B — broken

Downgrading to 0.0.33 resolves it completely. The sharp size drop between 0.0.33 and 0.0.34
suggests the packaging change that introduced this landed in 0.0.34.

No user-side workaround exists: Smart App Control has no per-application allow-list, so the
only options are staying on an old version or disabling Smart App Control system-wide — a
permanent reduction in OS security to run one app.

Suggested fix: Authenticode-sign the unpacked native addons as part of the Windows build,
using an RSA code-signing certificate from a trusted CA (Microsoft Trusted Signing is the
usual route). electron-builder does not sign bundled .node files by default — adding .node
to the signed extensions (win.signExts), or signing them in an afterPack hook, would cover it.

Related: #3125 — same silent crash-loop, different root cause (binding missing after
packaging pruned it, rather than present but blocked). Two distinct failure modes for this
one binding now produce an identical unrecoverable loop with no UI feedback, which seems
worth handling directly.

Impact

Blocks work completely

Version or commit

0.0.35 (broken). 0.0.33 confirmed working.

Environment

Windows 11 Pro x64 · T3 Code 0.0.35 desktop, x64 GitHub release installer · Smart App Control: On (enforcement mode)

Logs or stack traces

From ~/.t3/userdata/logs/server-child.log:

Error: An Application Control policy has blocked this file.
\\?\C:\Users\<user>\AppData\Local\Programs\t3code\resources\server.asar.unpacked\node_modules\@yuuang\ffi-rs-win32-x64-msvc\ffi-rs.win32-x64-msvc.node
    at process.func [as dlopen] (node:electron/js2c/node_init:2:2630)
    at Module._extensions..node (node:internal/modules/cjs/loader:1998:18)
    at Object.func [as .node] (node:electron/js2c/node_init:2:2857)
    at Module.load (node:internal/modules/cjs/loader:1560:32)
    at Module._load (node:internal/modules/cjs/loader:1362:12)
    at c._load (node:electron/js2c/node_init:2:18060)
    at wrapModuleLoad (node:internal/modules/cjs/loader:262:19)
    at Module.require (node:internal/modules/cjs/loader:1583:12)
    at require (node:internal/modules/helpers:153:16)
    at Object.<anonymous> (C:\Users\<user>\AppData\Local\Programs\t3code\resources\server.asar\node_modules\ffi-rs\index.js:66:29) {
  code: 'ERR_DLOPEN_FAILED'
}

backend child process failure output end ... pid=51668 code=1

Repeats every ~10 seconds.

---

Windows Code Integrity, Event ID 3077, log Microsoft-Windows-CodeIntegrity/Operational:

Code Integrity determined that a process
(\Device\HarddiskVolume3\...\Programs\t3code\T3 Code (Alpha).exe) attempted to load
\Device\HarddiskVolume3\...\resources\server.asar.unpacked\node_modules\@yuuang\ffi-rs-win32-x64-msvc\ffi-rs.win32-x64-msvc.node
that did not meet the Enterprise signing level requirements or violated code integrity policy.

Screenshots, recordings, or supporting files

No response

Workaround

Downgrade to 0.0.33, which is unaffected:

1. Close T3 Code and end any leftover processes.
2. Uninstall the current version. Thread data lives in ~/.t3 and is not touched by the uninstaller.
3. Install T3-Code-0.0.33-x64.exe from the v0.0.33 release.
4. Decline the update prompt, and clear any staged update in %LOCALAPPDATA%\t3code-updater\pending
   — otherwise it reapplies a broken build on next launch.

This avoids the affected builds rather than fixing anything. There is no way to allow the blocked
file while staying current: Smart App Control has no per-application allow-list, and disabling it
is system-wide.