CodexDesktop-Rebuild: packaging OpenAI's Codex desktop app with Electron Forge

What the rebuild actually rebuilds

The description line is two words long: Codex Desktop App, Cross-platform Rebuild. The README expands it as a cross-platform Electron build for the OpenAI Codex Desktop App, credited to OpenAI and to Cometix Space, with links to the original Codex CLI repository on GitHub and to `@cometix/codex` binaries on npm.

The important thing to understand is what this repository contains. Look at the file tree: `.github/`, `.gitignore`, `.npmignore`, `README.md`, `forge.config.js`, `package-lock.json`, `package.json`, `resources/` and `scripts/`. There is no `node_modules`, no upstream source, and no application logic committed. The `package.json` names `src/.vite/build/bootstrap.js` as the entry point, and that path does not exist until a build has fetched and prepared upstream code into it.

So the artifact of this repository is a toolchain. It downloads or accepts an upstream build, patches it, rebuilds native modules for the target platform, and hands the result to Electron Forge to package. The README's project structure block makes the split explicit, listing `src/.vite/build/` as the main process, `src/webview/` as the renderer, `resources/` for `electron.icns` and `notification.wav`, and `scripts/patch-copyright.js` as the one named script.

Platform support is claimed as a table, and Linux runs a macOS payload

The Supported Platforms section is a three-row table. macOS is listed for x64 and arm64, Windows for x64, and Linux for x64 and arm64, each with a check mark in the status column.

The release notes qualify that table in a way the README does not. Each of the three published releases, v26.623.61825, v26.623.70822 and v26.623.81905, all on 2026-07-02, carry an Upstream Versions table with a row for Linux whose value reads `uses macOS ASAR`. In other words, the Linux build is not a Linux-native upstream application repackaged. It is the macOS application archive, reused.

That is a real limitation and it belongs in any honest evaluation. A macOS ASAR running on Linux means the runtime expectations have not been adapted for a Linux windowing stack, a Linux sandbox and Linux filesystem conventions. It also means the Windows column in the Supported Platforms table is doing more work than the Linux column, because only Windows has its own upstream version numbers in those notes: `26.623.11225.0` and `26.623.9142.0` against the shared macOS value.

A second discrepancy is worth naming. The version field in `package.json` reads `26.917.62051`, while the newest published release tag is `v26.623.81905` from 2026-07-02 and the repository's last push was 2026-09-23. The tree has moved well past what has been tagged, which means the master branch and the downloadable artifacts describe different states of the packaging scripts.

The build commands, and what the platform scripts actually chain together

The README's build section is a single fenced block of npm commands, which is the whole installation story:

npm install
npm run build
npm run build:mac-x64

The README also lists `npm run build:mac-arm64`, `npm run build:win-x64`, `npm run build:linux-x64`, `npm run build:linux-arm64` and `npm run build:all` as the per-platform variants, and `npm run dev` for development.

The scripts in `package.json` show what those names do, and the contrast between platforms is the most informative thing in the file. The macOS and Windows builds are single invocations of `build-from-upstream.js` with a platform argument. The Linux builds are three-step chains: prepare the source for the platform, rebuild native modules, then sync native modules for that platform, followed by a clean of the `out` directory and an `electron-forge make` call with the platform and architecture flags.

The native module step is the reason for the chain. `npm run rebuild:native` runs `electron-rebuild`, and `sync-native-modules.js` copies the rebuilt binaries per platform. Any Electron application bundling native addons has to have those addons compiled against the target ABI, and doing that twice in a row is the visible cost of supporting x64 and arm64 Linux from one script.

Two more scripts deserve attention because they describe the ongoing maintenance burden. `npm run sync` calls `sync-upstream.js`, and `npm run check-update` calls `check-update.js`. Together they suggest the intended loop is pull a new upstream build, patch it, and see whether an update exists. There is also a `patch` script that fans out to `patch-all.js`, with per-platform variants for mac and win, and `patch-all.js` is what `patch-copyright.js` exists to serve.

GitHub Actions builds on push and drafts a release on tags

The CI/CD section is two bullets. GitHub Actions automatically builds on a push to `master`, and a tag matching `v*` creates a draft release. The `.github/` directory at the repository root is where those workflows live.

Draft releases are the detail that matters most here, and the three published releases are consistent with it. All three were created on the same day, 2026-07-02, within about twenty seconds of one another, which is what a tag-and-batch workflow looks like when several platform builds finish in one run. Their tag naming follows the upstream version rather than a package version, so a tag of `v26.623.81905` means the build tracked upstream release 26.623.81905.

Publishing to a draft rather than a live release is a sensible choice for a project that wraps someone else's application. It keeps a broken or misattributed build from being the obvious download, and it leaves a human to confirm what is in the archive before anyone gets it. The repository also carries a `.npmignore` alongside the usual `.gitignore`, which suggests the scripts directory is intended to be consumable as an npm package as well as a clone, matching the npm packages the credits section points at.

Licensing is the weakest part of the documentation

GitHub shows no licence for this project. The README has a License section, and it says two things: that this project rebuilds the Codex desktop app for cross-platform distribution, and that the original Codex CLI by OpenAI is licensed under Apache-2.0.

Read carefully, those two sentences cover upstream and leave this repository unaddressed. Apache-2.0 is stated for the Codex CLI; the desktop app that this project actually repackages is not named in the licence paragraph, and nothing in the README grants permissions for the Electron build this repository produces. There is also no LICENSE file in the repository tree, which for an MIT or Apache-licensed project would be unusual.

This is not a legal opinion, and it is not a reason to avoid the project. It is a documentation gap with a practical consequence: if you are going to redistribute a build produced by these scripts inside an organisation, the README as written does not tell you what terms you would be doing so under. Ask the maintainer, or read the upstream desktop app's own terms before you ship anything.

The credits section is otherwise clear about provenance. OpenAI Codex is credited as the original CLI under Apache-2.0, Cometix Space for the cross-platform rebuild and the `@cometix/codex` binaries, and Electron Forge as the build toolchain. Naming the upstream and the toolchain separately is the right way to make a repackaging project auditable.

Editorial conclusion

This repository is a packaging tool rather than a desktop application, and reading it that way sets the right expectation. It contains no Electron source of its own: `main` points at a bootstrap inside a generated `.vite/build` directory, and the real work is `prepare-src.js`, `build-from-upstream.js` and the native module sync that follows. That makes it useful to anyone who wants a Windows or Linux Codex desktop build today, and unhelpful to anyone who wants to change how Codex behaves, since the interface code is upstream's. Two things to check before depending on it: the gap between the version in `package.json` and the newest published release, and the licensing question, because the repository declares no licence while the README points only at the Apache-2.0 licence of the upstream CLI. Start with `npm run sync` to see what upstream revision you get, and build a single platform before trying `npm run build:all`.

Frequently asked questions

Official sources

1. Haleclipse/CodexDesktop-Rebuild on GitHub
2. Issues
3. README
4. Releases