[Bug]: Windows Smart App Control blocks unsigned native addons and crash-loops the desktop backend

[Lumbreras2306]

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 / apps/desktop

Summary

On Windows 11 with Smart App Control enforcement enabled, the signed T3 Code desktop executable starts, but Windows Code Integrity blocks native .node addons shipped under app.asar.unpacked because those addons are not Authenticode-signed.

The embedded backend then crash-loops with ERR_DLOPEN_FAILED, and the renderer becomes unusable with:

Primary environment request failed during fetch-session-state (HTTP 500).

The generic HTTP 500 screen hides the actual Windows application-control failure.

Steps to reproduce

1. Use Windows 11 with Smart App Control enabled in enforcement mode.
2. Install T3 Code Alpha 0.0.33 x64.
3. Launch T3 Code.
4. Observe the full-screen fetch-session-state (HTTP 500) error.
5. Inspect %USERPROFILE%\.t3\userdata\logs\server-child.log.
6. Inspect Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational.

Expected behavior

T3 Code should package Windows native addons in a form trusted by Smart App Control (for example, Authenticode-sign each unpacked native addon or provide equivalent trusted package/catalog coverage), allowing the embedded backend to start.

If a native addon is blocked, the desktop app should surface the underlying application-control error instead of only reporting a generic session-state HTTP 500.

Actual behavior

The main executable has a valid signature from T3 Tools Inc, but at least these packaged native addons report NotSigned:

resources\app.asar.unpacked\node_modules\@yuuang\ffi-rs-win32-x64-msvc\ffi-rs.win32-x64-msvc.node
resources\app.asar.unpacked\node_modules\@clerk\electron-passkeys\electron-passkeys.win32-x64-msvc.node

Windows Code Integrity blocks both. The ffi-rs block is fatal to the embedded backend, which exits with code 1 and is repeatedly restarted by the desktop process.

Impact

Blocks work completely.

Version or commit

T3 Code Alpha 0.0.33.0 (file version 0.0.33).

Environment

• Windows 11 Home Single Language 25H2, build 26200.9168
• x64 / AMD64
• Embedded backend runtime reports Node.js v24.15.0
• Smart App Control enforcement policy ID: {0283ac0f-fff1-49ae-ada1-8a933130cad6}

Logs or stack traces

Error: error: 4551\\?\C:\Users\<user>\AppData\Local\Programs\t3code\resources\app.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 Object.<anonymous> (...\resources\app.asar\node_modules\ffi-rs\index.js:66:29) {
  code: 'ERR_DLOPEN_FAILED'
}

Node.js v24.15.0

Windows maps error 4551 to:

An Application Control policy has blocked this file.

Code Integrity records enforcement events 3033 and 3077:

Code Integrity determined that T3 Code (Alpha).exe attempted to load
...\@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 (Policy ID:{0283ac0f-fff1-49ae-ada1-8a933130cad6}).

The same events are recorded for:

...\@clerk\electron-passkeys\electron-passkeys.win32-x64-msvc.node

Related issues (not duplicates)

• [Bug]: Nightly desktop backend crash-loops due to missing ffi-rs native optional dependency (WORKAROUND INCLUDED) #3104 and [Bug]: Nightly desktop app never opens a window — backend crash-loops on missing @yuuang/ffi-rs native binding #3125: ffi-rs native package was missing from packaged builds (MODULE_NOT_FOUND).
• [Bug]: last 24 hours of Nightly's failing to start on Windows 10 #3807: Windows startup regression from the same earlier packaging class.
• [Bug]: Failed startup session probe bricks the app — fatal, sticky error in root beforeLoad with no recovery #3513: the startup session probe can brick the UI and the displayed HTTP 500 can be a fallback label.

Here the native files are present, but Smart App Control rejects them because they are unsigned.

Suggested fix

• Authenticode-sign every executable/native Windows artifact shipped outside the signed top-level executable, including unpacked .node addons.
• Add a Windows release check that enumerates executable/native artifacts and fails if their trust/signature coverage is missing.
• Ideally include a Smart App Control enforcement smoke test.
• Preserve the underlying ERR_DLOPEN_FAILED / Windows error 4551 in the user-visible startup error and diagnostics.

Workaround

Disable Smart App Control globally and relaunch/restart Windows. This lowers system protection, and Smart App Control has no supported per-app allowlist, so it is not a good long-term workaround.