Skip to content
opencodex

Windows Code Signing

OpenCodex is moving its Windows downloads, the standalone ocx.exe and the desktop installer OpenCodex-<version>-windows-x64.msi, to Authenticode code signing through SignPath Foundation. A signed file tells Windows, SmartScreen and antivirus products who published it and that nobody changed it after the build, which is what stops unsigned-binary false positives like the one reported in #7207.

Signing is rolling out. The release workflow is wired, and SignPath is validating it with a test certificate. Until the production certificate is issued, Windows release files stay unsigned, and SmartScreen may ask once (More info → Run anyway). Releases published after that switch carry a signature from SignPath Foundation.

Code signing policy

Section titled “Code signing policy”

Free code signing provided by SignPath.io, certificate by SignPath Foundation.

Every signing request for a release is approved by hand in SignPath before the certificate is used. Only binaries built from this repository’s source by GitHub Actions are signed. Third-party files bundled with a release, such as the prebuilt keyring addons, keep their upstream form; the SignPath Foundation policy forbids signing them with the project certificate.

Privacy

Section titled “Privacy”

opencodex sends one anonymous daily usage summary (a per-day install hash that changes daily, version, release channel, platform, install channel, provider kind, coarse model family, active minutes and request, token and error counts; never prompts, model outputs, keys, accounts, hostnames or paths) to telemetry.opencodex.me, and only after the person installing or operating it has seen the notice in the dashboard or an interactive CLI prompt and has not declined. It can be turned off in that notice, in the Windows installer (“Send anonymous usage statistics”, checked by default), in Proxy details, or with ocx telemetry disable, OCX_TELEMETRY=0 or DO_NOT_TRACK=1. Only project-wide aggregates of this anonymous data are public. A separate public leaderboard profile is off unless you connect one yourself (dashboard Home or ocx telemetry profile connect); it shares only a chosen handle, display name and colour and your daily request, token and model-family totals, never your anonymous telemetry ID, and disconnecting deletes it. Everything else goes only to the providers and services you configure. To look for new versions, opencodex also reads release metadata from GitHub and the npm registry, and those version checks carry none of your prompts or credentials. See Telemetry and Privacy.

Verifying a download

Section titled “Verifying a download”

In PowerShell, check the file you downloaded:

Terminal window
Get-AuthenticodeSignature .\OpenCodex-<version>-windows-x64.msi | Format-List Status, SignerCertificate
Get-AuthenticodeSignature .\ocx.exe | Format-List Status, SignerCertificate

A signed release reports Status : Valid and a signer certificate whose subject names SignPath Foundation. In Explorer, the same information is under Properties → Digital Signatures. Every release file also has a .sha256 next to it on the release page, which you can compare with Get-FileHash <file> -Algorithm SHA256.

What gets signed

Section titled “What gets signed”
File Signed contents
ocx-<version>-bun-windows-x64.zip ocx.exe inside the archive. The zip and its .sha256 are built from the signed binary.
OpenCodex-<version>-windows-x64.msi The installer, plus every .exe it installs (the desktop app and its bundled ocx.exe).

The desktop updater signature (.msi.sig) and latest.json are produced from the signed installer, so in-app updates install the same bytes the release page offers.

For maintainers

Section titled “For maintainers”

The release workflow (.github/workflows/release.yml) signs through the official signpath/github-action-submit-signing-request action. It reads one secret and three repository variables:

Name Kind Value
SIGNPATH_API_TOKEN secret API token of the SignPath CI user
SIGNPATH_ORGANIZATION_ID variable SignPath organization ID
SIGNPATH_PROJECT_SLUG variable opencodex
SIGNPATH_SIGNING_POLICY_SLUG variable test-signing today; release-signing once the certificate is issued

SignPath artifact configurations: windows-standalone-zip (one ocx.exe at the zip root) and windows-msi-zip (one .msi at the zip root, deep-signed).

Signing never blocks a release. What a run does depends on the policy:

Policy Dry run Real release
No token, or an incomplete configuration Unsigned Unsigned, with a notice or warning
test-signing Signed with the test certificate, kept only as a workflow artifact Unsigned, with a notice; a test certificate never ships
release-signing Signed and verified as trusted Signed and verified as trusted

If a signing request fails, times out or is rejected, or if verification fails, the job logs a warning and ships the unsigned file together with its original updater signature.

Switching to the production certificate. Once SignPath issues it, set the repository variable SIGNPATH_SIGNING_POLICY_SLUG to release-signing (Settings → Secrets and variables → Actions → Variables). No workflow change is needed. From then on, every release, including a dry run, opens two signing requests (the standalone binary and the installer). An approver must approve both in app.signpath.io while the run waits. The workflow waits up to an hour per request before it gives up and ships unsigned.

Testing without publishing. The Windows signing test workflow (.github/workflows/windows-signing-test.yml, manual dispatch only, no inputs) builds ocx.exe and the MSI on GitHub-hosted Windows runners, signs both with test-signing, verifies the signatures, and keeps the test-signed files as short-lived workflow artifacts. It publishes nothing and never uses the release policy.