codex-app-mirror: a verifiable installer mirror for the Codex desktop app

What codex-app-mirror actually distributes

This is not a Codex client and not a fork of one. It is a distribution channel. The README states that the project only mirrors: it does not build, modify or repackage the installers. Stable releases carry the official Windows MSIX and macOS DMG files, published unchanged to GitHub Releases and served through CDN short links. Linux is handled separately: the unified ChatGPT desktop app that includes Codex entered a Linux Preview on 2026-08-11, and those DEB and RPM packages go to a standalone GitHub prerelease rather than the stable channel.

The audience is narrow and specific. It is for people who cannot reach the Microsoft Store or the official download endpoints reliably, and who still want the genuine installer rather than a third-party build. The project's own framing is availability, not features. If your normal download path works, this adds a middleman with no functional gain.

Probe, compare, publish: the mirror pipeline

The mechanism is a change-detection loop. Each run probes upstream lightly, and only downloads and publishes when something upstream has actually changed. For Windows, the README says the pipeline queries the Microsoft Store DisplayCatalog for x64 and ARM64 package metadata, then resolves the downloadable MSIX moniker and a temporary Microsoft CDN URL from FE3 metadata. If the ARM64 URL is not resolvable at that moment, the run records it as catalog-only in the manifest instead of publishing a package.

For macOS, the probe is an HTTP request against the official DMG and appcast, reading ETag, Last-Modified and Content-Length plus the appcast version fields. For Linux Preview, the job verifies the official APT InRelease and RPM repomd.xml against a pinned public key, resolves the four versioned package URLs, and then checks the downloaded artifacts for package name, version, architecture, file list, embedded public key and RPM package signature.

Scheduling is split. A Cloudflare Cron job is the primary scheduler, with GitHub Actions running every six hours as a fallback. The badge in the README advertises a 15-minute probe interval. The important consequence is that this is a polling mirror: it cannot publish a release before it has observed the upstream change, so there is always a detection window between an official release and its appearance here.

Installing from the mirror and checking what you got

The README directs you to the latest GitHub Release, where the platform files are named by architecture: the Windows x64 and ARM64 MSIX packages, and Codex-mac-arm64.dmg for Apple Silicon or Codex-mac-x64.dmg for Intel. It also lists CDN short links that it says pick a node automatically, with mainland China traffic going to an S3 secondary mirror and other regions to Cloudflare R2. Only the current version sits behind a short link:

curl -L -O https://codexapp.agentsmirror.com/latest/win-x64
curl -L -O https://codexapp.agentsmirror.com/latest/mac-arm64
curl -L -O https://codexapp.agentsmirror.com/latest/checksums

The third link returns the checksum list. The README recommends downloading SHA256SUMS.txt alongside the installer and checking the file's integrity against it, and it also exposes a release manifest at /latest/manifest carrying upstream fingerprints. Do that comparison before you install anything. The mirrors' whole claim rests on the file matching what upstream published.

If you need an older build, the short links will not help, because the README says they only ever point at the newest version. Historical files live in the GitHub Releases list, where you find them by release or tag. On Linux, the README notes that the official package configures OpenAI's own update repository after installation, so later updates come directly from OpenAI rather than from this mirror.

The macOS delta feed and why the signature still validates

The macOS side does more than host a DMG. The project publishes a Sparkle appcast at /latest/appcast.xml for Apple Silicon and /latest/appcast-x64.xml for Intel, and a downstream client, Codex App Manager, subscribes to it. That client downloads delta packages between versions rather than the full installer each time.

The interesting part is the signature handling. The README states that the mirror copies the official Sparkle archive and OpenAI's EdDSA signature byte for byte, and rewrites only the enclosure download URL to point at the mirror. Because EdDSA signs the archive bytes themselves, a byte-identical copy keeps the original signature valid. The README is explicit that the mirror does not and cannot forge a signature. That is a sound design, and it is also the project's main structural guarantee: the mirror's integrity claim rests on byte fidelity, not on its own signing key.

The practical caveat is that the feed only helps if your client matches a delta. The README says a client without a matching delta falls back to the full archive automatically.

Where the mirror model breaks down

The most obvious limitation is scope. There is no Android build, no iOS build and no web app in this pipeline. The topics and the README cover Windows, macOS and a Linux preview only. Someone searching for a Codex mobile client will not find one here, and the repository does not claim otherwise.

The second limitation is latency by design. A polling mirror is always behind. If you need the release the moment OpenAI ships it, the official channel is the only one without a detection delay.

The third is the trust question the project cannot fully solve on its own. Byte-level fidelity is verifiable in principle, but only if you actually verify. The README recommends downloading SHA256SUMS.txt and checking the file, and the manifest records upstream fingerprints. Skip that step and you are trusting an intermediary with an installer you will run with your own privileges. On Windows, the README notes that ARM64 packages are published only when the official download URL has been resolved; when it has not, the manifest records catalog-only. So an ARM64 user can hit a release where the file simply is not there yet.

Finally, the Linux preview is deliberately isolated: it does not advance GitHub Latest, does not upload to R2 or S3, and creates no latest/linux short link. That keeps stable clean, but it also means Linux users must browse the releases list by hand instead of using a stable URL.

Alternatives and the difference in approach

The direct alternative is the official channel itself: the Microsoft Store on Windows, the official DMG and appcast on macOS, and OpenAI's APT and RPM repositories on Linux. That path has no intermediary and no detection delay, and it is the right choice when it is reachable. The difference is not quality of the artifact, since the mirror ships the same bytes; it is reachability and update mechanics.

A second alternative is Codex App Manager, a separate project by the same author that the README describes as a desktop client built on this mirror. It installs, updates and uninstalls Codex for you and consumes the Sparkle appcast for incremental updates. The distinction is interface: codex-app-mirror gives you files and a feed, while Codex App Manager gives you a GUI that automates the same underlying downloads. If you want manual control and your own checksum verification, use the mirror directly. If you want the update loop handled for you, the client is the layer above it.

Maintenance, licensing and what the project does not promise

The repository is MIT licensed and is not archived. The last push was on 2026-09-16, and the most recent release, codex-app-26.911.61220, carries the same timestamp, which is consistent with a release published by the pipeline on the day it detected a change. Two earlier releases landed on 2026-09-14 and 2026-09-11, so the cadence follows upstream rather than a fixed schedule of its own.

Upgrade cost for a user is close to zero: the mirror has no runtime component to install, and the macOS delta feed exists precisely to avoid re-downloading full installers. The cost sits with the maintainer instead. Every run depends on upstream endpoints continuing to behave: Store metadata fields, ETag and Last-Modified headers, APT and RPM repository signing. Any of those changing shape breaks detection, and the README does not document a fallback for a probe that starts returning unexpected data.

On licensing, note only this: the MIT licence covers the mirror's own code, not the Codex installers it redistributes. Those remain OpenAI's, and the README's own framing is that the project republishes them unchanged.

Editorial conclusion

Adopt codex-app-mirror if you are on Windows or macOS, need a Codex desktop installer now, and are willing to compare the downloaded file against SHA256SUMS.txt before running it. Do not adopt it if you need Android, iOS or a web client, because the project mirrors only Windows MSIX, macOS DMG and a Linux preview, and the README documents no mobile or browser build. Verify the checksum against the release manifest first, and on macOS confirm the appcast still carries OpenAI's EdDSA signature before pointing a client at it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Wangnov/codex-app-mirror on GitHub