What

Three Windows-only reliability fixes, surfaced by an enterprise fleet running the screenpipe CLI embedded inside their own Electron wrapper (audio disabled, a few hundred machines). On Windows the CLI exited far more than on macOS, almost always in the first minute after spawn.

Why / evidence

Reading the binary at the customer's version and at HEAD turned up three concrete, still-present issues.

1. The npm CLI binary ships unsigned -> "Unknown publisher" + Defender kills

Only the desktop app bundle is signed (SSL.com EV, in release-app.yml). release-cli.yml's only signing step was macOS codesign. So integrators bundling @screenpipe/cli-win32-x64 ship an unsigned screenpipe.exe, which is what Windows flags as "Unknown publisher" and what corporate Defender/EDR scrutinizes (correlates with managed-machine crash spikes + external-kill exit codes).

Fix: sign screenpipe.exe with the same SSL.com eSigner cert/flow the app uses, reusing sign-ssl.ps1 (retry/backoff + quota detection). Only our one PE is signed (bundled DLLs are already vendor-signed), so this costs exactly one signing-quota unit per release. Safely no-ops when ESIGNER_* secrets are absent (forks/PRs).

2. --auto-destruct-pid self-destructs under any non-Tauri host (clean exit 0)

watch_pid on Windows checked the watched PID and additionally required a process named screenpipe-app.exe (our Tauri app) to be running:

let app_alive = !tasklist("IMAGENAME eq screenpipe-app.exe").is_empty();
if !pid_alive || !app_alive { return true; } // -> graceful shutdown, exit 0

In a third-party wrapper that image name is never present, so the watcher fires on its first tick and the binary exits 0 within seconds. It also spawned two tasklist subprocesses every tick.

Fix: watch only the PID we were given, via the Windows API check that already ran first. Removes the hardcode and the per-tick subprocesses.

3. VC++ runtime DLLs bundled best-effort -> silent STATUS_DLL_INIT_FAILED

vcruntime140_1.dll and msvcp140.dll were copied with -ErrorAction SilentlyContinue, so a runner missing one silently shipped an incomplete package that dies with 0xC0000142 on machines without the VC++ redistributable.

Fix: hard-fail if any of the three required DLLs is missing on the runner or absent from the package.

Flow (before -> after)

flowchart TD
    subgraph BEFORE["watch_pid on Windows (before)"]
      A1[every 5s] --> A2{PID alive?}
      A2 -- no --> A3[shutdown, exit 0]
      A2 -- yes --> A4{"screenpipe-app.exe running?"}
      A4 -- "no: always, for 3rd-party host" --> A3
      A4 -- yes --> A1
    end
    subgraph AFTER["watch_pid on Windows (after)"]
      B1[every 5s] --> B2{PID alive?}
      B2 -- no --> B3[shutdown, exit 0]
      B2 -- yes --> B1
    end

flowchart LR
    Build["cargo build screenpipe.exe"] --> Sign{"ESIGNER_* secrets?"}
    Sign -- yes --> S1["sign-ssl.ps1 SSL.com EV, verify Authenticode=Valid"]
    Sign -- "no: fork/PR" --> S2["no-op, unsigned"]
    S1 --> Pkg["bundle exe + DLLs"]
    S2 --> Pkg
    Pkg --> VC{"all 3 VC++ DLLs present?"}
    VC -- no --> Fail["fail the build"]
    VC -- yes --> Zip["zip + upload"]

Testing / verification

• rustfmt --check clean on auto_destruct.rs; workflow YAML parses.
• The #[cfg(target_os = "windows")] path and the signing step can only be exercised on the Windows release runner (can't cross-compile/sign on macOS). The Rust change only removes code + an import and reuses the unchanged is_process_alive, so risk is low; the signing step reuses the app's proven sign-ssl.ps1.
• release-cli.yml runs only on tag / release-bump commits to main / manual dispatch (not on PRs), so this won't sign or spend quota until an actual release.

Notes

• Does not touch the macOS path or the non-Windows watcher.
• Quota impact: +1 SSL.com sign per CLI release.
• Out of scope (follow-ups): --disable-audio integrators should still ship the full bin/; consider DXGI device-lost recovery so the binary survives sleep without a wrapper kill/respawn.

🤖 Generated with Claude Code