Windows: Smart App Control blocks the app — only the installer is signed, not the binaries it installs
Summary
The Windows installer is validly signed by Logseq, Inc., but every binary it
installs is unsigned. On Windows 11 with Smart App Control (SAC) enabled,
Code Integrity blocks Logseq-OG.exe at load time and the app cannot start.
SAC has no per-app override — no "Run anyway", no exclusion list, and running as
administrator does not bypass it. The only user-side workaround is disabling SAC
system-wide, which is a poor trade and was historically irreversible without
reinstalling Windows.
Environment
- Logseq-OG 1.0.0,
Logseq-OG-win-x64-1.0.0.exe
- Windows 11, build 26200
- Smart App Control: On (enforcing) —
VerifiedAndReputablePolicyState = 1
Note: the app installed and ran fine for ~2 weeks while SAC was in Evaluation
mode, then broke with no change to Logseq when Windows promoted SAC to enforcing
(SAC_PreviousState = 2, SAC_EnforcementReason = 1).
What happens
Launching from the Start menu, desktop shortcut or directly does nothing —
no window, no error dialog. Microsoft-Windows-CodeIntegrity/Operational logs
events 3033 and 3077 on every attempt:
Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\explorer.exe)
attempted to load \Device\HarddiskVolume3\Users\<user>\AppData\Local\Logseq-OG\Logseq-OG.exe
that did not meet the Enterprise signing level requirements or violated code integrity policy
(Policy ID:{0283ac0f-fff1-49ae-ada1-8a933130cad6}).
Signature audit
Get-AuthenticodeSignature on the shipped 1.0.0 artifacts:
| Binary |
Status |
Logseq-OG-win-x64-1.0.0.exe (installer) |
Valid — CN="Logseq, Inc.", timestamped |
%LOCALAPPDATA%\Logseq-OG\Logseq-OG.exe (Squirrel stub) |
NotSigned ← blocked |
%LOCALAPPDATA%\Logseq-OG\Update.exe |
NotSigned |
app-1.0.0\Logseq-OG.exe (Electron main) |
NotSigned |
app-1.0.0\squirrel.exe |
NotSigned |
app-1.0.0\ffmpeg.dll, libEGL.dll, libGLESv2.dll, vk_swiftshader.dll, vulkan-1.dll, dxcompiler.dll |
NotSigned |
(The bundled Git for Windows and Git Credential Manager binaries are signed by
their own publishers and are not the problem.)
Root cause
forge.config.js signs macOS thoroughly but Windows only at the installer step:
packagerConfig: {
osxSign: { identity: 'Developer ID Application: Logseq Inc. (K378MFWK59)', ... },
osxNotarize: { tool: 'notarytool', ... },
// no windowsSign — packaged Windows binaries are never signed
},
makers: [
{ name: '@electron-forge/maker-squirrel',
config: { certificateFile: process.env.CODE_SIGN_CERTIFICATE_FILE, ... } } // signs Setup.exe only
]
osxSign signs everything inside the macOS bundle. There is no Windows
equivalent configured, so maker-squirrel's certificate covers only the
generated installer — the app's own executables ship unsigned.
Suggested fix
Add a windowsSign entry to packagerConfig so the same signing identity
already used for the installer is applied to the packaged binaries before the
maker runs (Electron Forge v7 supports this via @electron/windows-sign). That
should cover the Electron main exe and DLLs; the Squirrel stub and Update.exe
need to be signed as well, since the stub is the binary SAC actually blocks.
This needs no new certificate — just wider application of the existing one.
Why this will affect more users
SAC ships enabled on many new Windows 11 installs, starts in Evaluation mode, and
promotes itself to enforcing once a machine looks clean. Users who installed
successfully will have the app stop launching later, with no error message and no
obvious cause. Signed-but-unsigned-payload Electron apps are hitting this broadly
in 2026 (see e.g. openai/codex#32487, trycua/cua#2118).
Not a tampering report
For the avoidance of doubt, the build I have is authentic — SHA-256 matches
SHA256SUMS.txt for 1.0.0 exactly, and the installer's Authenticode chain is
valid. This is purely about which binaries get signed.
AI disclosure
This issue was prepared with the assistance of Claude Code. The diagnostics it
reports — the Authenticode signature audit, the CodeIntegrity event capture, the
SHA-256 verification against SHA256SUMS.txt, and the forge.config.js
analysis — were all run against a real affected installation on my machine.
Windows: Smart App Control blocks the app — only the installer is signed, not the binaries it installs
Summary
The Windows installer is validly signed by
Logseq, Inc., but every binary itinstalls is unsigned. On Windows 11 with Smart App Control (SAC) enabled,
Code Integrity blocks
Logseq-OG.exeat load time and the app cannot start.SAC has no per-app override — no "Run anyway", no exclusion list, and running as
administrator does not bypass it. The only user-side workaround is disabling SAC
system-wide, which is a poor trade and was historically irreversible without
reinstalling Windows.
Environment
Logseq-OG-win-x64-1.0.0.exeVerifiedAndReputablePolicyState = 1Note: the app installed and ran fine for ~2 weeks while SAC was in Evaluation
mode, then broke with no change to Logseq when Windows promoted SAC to enforcing
(
SAC_PreviousState = 2,SAC_EnforcementReason = 1).What happens
Launching from the Start menu, desktop shortcut or directly does nothing —
no window, no error dialog.
Microsoft-Windows-CodeIntegrity/Operationallogsevents 3033 and 3077 on every attempt:
Signature audit
Get-AuthenticodeSignatureon the shipped 1.0.0 artifacts:Logseq-OG-win-x64-1.0.0.exe(installer)CN="Logseq, Inc.", timestamped%LOCALAPPDATA%\Logseq-OG\Logseq-OG.exe(Squirrel stub)%LOCALAPPDATA%\Logseq-OG\Update.exeapp-1.0.0\Logseq-OG.exe(Electron main)app-1.0.0\squirrel.exeapp-1.0.0\ffmpeg.dll,libEGL.dll,libGLESv2.dll,vk_swiftshader.dll,vulkan-1.dll,dxcompiler.dll(The bundled Git for Windows and Git Credential Manager binaries are signed by
their own publishers and are not the problem.)
Root cause
forge.config.jssigns macOS thoroughly but Windows only at the installer step:osxSignsigns everything inside the macOS bundle. There is no Windowsequivalent configured, so
maker-squirrel's certificate covers only thegenerated installer — the app's own executables ship unsigned.
Suggested fix
Add a
windowsSignentry topackagerConfigso the same signing identityalready used for the installer is applied to the packaged binaries before the
maker runs (Electron Forge v7 supports this via
@electron/windows-sign). Thatshould cover the Electron main exe and DLLs; the Squirrel stub and
Update.exeneed to be signed as well, since the stub is the binary SAC actually blocks.
This needs no new certificate — just wider application of the existing one.
Why this will affect more users
SAC ships enabled on many new Windows 11 installs, starts in Evaluation mode, and
promotes itself to enforcing once a machine looks clean. Users who installed
successfully will have the app stop launching later, with no error message and no
obvious cause. Signed-but-unsigned-payload Electron apps are hitting this broadly
in 2026 (see e.g.
openai/codex#32487,trycua/cua#2118).Not a tampering report
For the avoidance of doubt, the build I have is authentic — SHA-256 matches
SHA256SUMS.txtfor 1.0.0 exactly, and the installer's Authenticode chain isvalid. This is purely about which binaries get signed.
AI disclosure
This issue was prepared with the assistance of Claude Code. The diagnostics it
reports — the Authenticode signature audit, the CodeIntegrity event capture, the
SHA-256 verification against
SHA256SUMS.txt, and theforge.config.jsanalysis — were all run against a real affected installation on my machine.