Windows in-app update silently fails when the installer signature check exceeds electron-updater's 20s PowerShell timeout#20345

What happened

On a corporate-managed Windows 11 machine, the in-app update never completes. Clicking download shows progress up to 100%, then the update quietly goes nowhere. No visible error appears. The same nightly updates fine on a personal Windows machine.

Diagnosis

The download itself succeeds. The failure is electron-updater's Windows signature check, which runs after the download and before the temp file is renamed into place.

• NsisUpdater calls verifySignature() from windowsExecutableCodeSignatureVerifier.js. That function spawns powershell.exe ... Get-AuthenticodeSignature -LiteralPath '<temp file>' | ConvertTo-Json -Compress through execFile with a hardcoded timeout: 20 * 1000.
• On machines with endpoint security that scans a newly written ~240 MB executable on first open (and/or inspects PowerShell launches), that first Get-AuthenticodeSignature call can take longer than 20 s. Node kills the child, and the rejection is Error: Command failed: <command> with empty stderr.
• The failure was logged 27.1 s after download progress: 100. That gap is consistent with SHA-512 verification plus the 20 s kill.
• After the failure, I re-ran the exact same command by hand against the same file. It completed in 4.2 s with Status: 0 (Valid) and signer CN=T3 Tools Inc. So the file and signature are fine; only the first, scan-blocked invocation is slow. PowerShell runs in FullLanguage mode on this machine, so the check is not blocked by policy.
• The leftover pending/temp-T3-Code-0.1.1-nightly.20261016.3218-x64.exe is exactly 242,348,152 bytes, and its SHA-512 matches nightly.yml for that release.

T3 Code does not override verifyUpdateCodeSignature (apps/desktop/src/electron/ElectronUpdater.ts), so it inherits the 20 s limit. describeUpdateErrorCause keeps only message and string code. That drops killed: true / signal: "SIGTERM", so the trace can't tell a timeout apart from a real signature failure.

Steps to reproduce

Depends on the endpoint-security stack, so it is not deterministic everywhere:

1. On a Windows machine with real-time/EDR scanning of newly written executables under %LOCALAPPDATA%, run a nightly build.
2. Open the update flyout and download the available update.
3. Progress reaches 100%, then the update does not become ready to install. desktop.trace.ndjson shows ElectronUpdaterDownloadUpdateError with the Get-AuthenticodeSignature command as the cause.
4. %LOCALAPPDATA%\t3code-updater\pending\ keeps a full-size temp-*.exe that never gets promoted.

Without that kind of AV, a unit test can stand in: make the injected verifier reject the way execFile does on timeout (killed: true, empty stderr).

Version

0.0.46-nightly.20261015.3145, updating to 0.1.1-nightly.20261016.3218. electron-updater ^6.8.9 per apps/desktop/package.json on main.

Environment

Windows 11 Enterprise 10.0.26100 x64, corporate-managed (endpoint security, no admin rights), desktop app per-user NSIS install, nightly channel.

Evidence

Related issues

• #6035: same failed to download the update string on Windows, but it failed in ~200 ms (before any download), so it's a different cause.
• #11708: same string, but the reporter traced it to a failing SSD.
• #4812: same string, but on macOS behind a TLS-inspecting proxy, stalling at 0%.

I found no existing electron-builder issue about this timeout.

Fix applied or workaround

Nothing changed on the machine. Workaround: close T3 Code and run the leftover pending\temp-*.exe (after checking its SHA-512 against nightly.yml), or download the installer from the release page. Neither needs admin rights.

Suggested fixes

NsisUpdater already exposes a setter for this check: autoUpdater.verifyUpdateCodeSignature = (publisherNames, path) => Promise<string | null>. electron-updater's own docs suggest it for custom verification. Options, smallest first:

1. Retry the default verifier on timeout (Windows only). Capture the original autoUpdater.verifyUpdateCodeSignature, wrap it, and retry once or twice when the rejection is a killed child process (error.killed === true). The second run is fast because the AV scan of the file is already done and cached (4.2 s here). Publisher matching and the security posture stay exactly the same. The logic is a few lines in ElectronUpdater.ts, plus a unit test for timeout → retry → success, and for a real mismatch still failing.
2. Avoid spawning PowerShell entirely. Verify with WinVerifyTrust in-process, for example via win-verify-trust, which the electron-updater docs mention. This removes the 20 s limit, the PowerShell process launch that endpoint security tends to inspect, and the PSModulePath/chcp workarounds.
3. Make timeouts diagnosable. Have describeUpdateErrorCause include killed/signal (and numeric exit codes) for child-process errors, or tag signature-verification failures distinctly, so Command failed: with empty stderr shows up as a timeout.
4. Surface the failure. The user saw no error. A download failure with a short hint ("Signature verification timed out — security software may be scanning the installer. Retry?") would make this self-service.

A configurable timeout in electron-updater itself would also help, but options 1 or 2 are fully within T3 Code's control.

Filed by

Claude Code (claude-opus-5-5), investigating by hand following .github/triage/PLAYBOOK.md, not via npx t3 triage.