Windows Smart App Control blocks the bundled native modules — dcli cannot start at all

[hayama-h]

Summary

On a Windows 11 machine with Smart App Control (SAC) enabled and enforcing, dcli cannot start. Every command fails, including dcli --version.

The root cause is that dcli.exe itself is correctly Authenticode-signed, but the native modules it extracts at runtime into %USERPROFILE%\.cache\pkg\... are unsigned. SAC evaluates signature and cloud reputation at DLL load time, so process.dlopen is refused.

There is no workaround available to the user: SAC has no per-file allowlist, and turning SAC off is irreversible (it cannot be re-enabled without reinstalling Windows).

Environment

OS	Windows 11 25H2, build 26200.8875
dcli	22.11.0 (packaged executable, Windows x64, from the releases page)
Smart App Control	Enabled and enforcing (VerifiedAndReputablePolicyState = 1)

Steps to reproduce

1. Use a Windows 11 machine where Smart App Control is enabled (clean install; SAC left on after the evaluation period).
2. Install the packaged dcli.exe for Windows.
3. Run any command, e.g. dcli --version.

Actual result

Error: An Application Control policy has blocked this file.
C:\Users\<user>\.cache\pkg\<hash>\@napi-rs\clipboard-win32-x64-msvc\clipboard.win32-x64-msvc.node
    at process.dlopen (pkg/prelude/bootstrap.js:2260:28)
    at Object..node (node:internal/modules/cjs/loader:1719:18)
    at Module.load (node:internal/modules/cjs/loader:1322:32)
    at Function._load (node:internal/modules/cjs/loader:1132:12)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:218:24)
    at Module.<anonymous> (node:internal/modules/cjs/loader:1344:12)
    at Module.require (pkg/prelude/bootstrap.js:1855:31)
    at require (node:internal/modules/helpers:141:16)
    at Object.<anonymous> (C:\snapshot\dashlane-cli\node_modules\@napi-rs\clipboard\index.js:104:29)

Exit code 1. This happens for --version and status as well, i.e. before any vault access, so the CLI is completely unusable rather than degraded.

Signature status

Checked with Get-AuthenticodeSignature:

File	Signature
dcli.exe	Valid
@napi-rs/clipboard → clipboard.win32-x64-msvc.node	NotSigned
@napi-rs/keyring → keyring.win32-x64-msvc.node	NotSigned
better-sqlite3 → better_sqlite3.node	NotSigned
argon2 → argon2.win32-x64-msvc.node	NotSigned

So signing the launcher alone is not sufficient — SAC checks every module that is loaded.

Windows CodeIntegrity event log

Microsoft-Windows-CodeIntegrity/Operational confirms SAC is the enforcer (not audit mode):

Event 3118  Smart App Control Block Details

Event 3077  Code Integrity determined that a process (...\dashlane-cli\dcli.exe) attempted to load
            ...\.cache\pkg\<hash>\@napi-rs\clipboard-win32-x64-msvc\clipboard.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}).

Things that do NOT fix it

• "Unblock" in file properties — neither dcli.exe nor the .node files carry a Zone.Identifier stream (the .node files are extracted by dcli itself at runtime, so they never receive a Mark of the Web). The checkbox does not even appear. That mechanism addresses SmartScreen, not SAC.
• Reinstalling dcli — a fresh install extracts the same unsigned modules.
• Clearing .cache\pkg — the modules are re-extracted unsigned.

Note on timing

On this machine dcli worked normally until 2026-07-31, and was blocked by 2026-08-02, with:

• no reboot in between (SAC mode changes require one),
• no change to the local SAC policy files,
• no dcli update,
• SAC_PreviousState = 0xFFFFFFFF (SAC state never toggled).

Since SAC also consults cloud reputation, this looks like a reputation verdict change rather than a local configuration change. That matters because it means users can be broken without doing anything, and it may equally affect users who currently work fine.

Request

Please Authenticode-sign the bundled native modules as part of the release pipeline for the packaged Windows executable, not just dcli.exe.

Signing the redistributed .node binaries would make the CLI usable on Smart App Control machines. As it stands, dcli is unusable on such machines with no user-side remedy.