codex-desktop-linux: an unofficial ChatGPT desktop build for Linux

What codex-desktop-linux actually distributes

This is not a fork of the ChatGPT client. The README describes it as an unofficial, community-maintained distribution of OpenAI's official Linux ChatGPT desktop application: it verifies and repackages the signed upstream Linux payload rather than patching an Electron app from source. The upstream source is OpenAI's signed .deb, resolved through the signed stable APT metadata for amd64 or arm64. Everything inside it, including the Electron runtime, native modules, the bundled codex and rg binaries, the code-mode host, plugins, libraries, locales and Owl metadata, is reused as-is.

The audience is narrow and specific. You are on Linux, you want the desktop client rather than the web app, and your distribution is not served by an official package you can simply install. Debian and Ubuntu derivatives, Fedora, openSUSE, Arch and its derivatives, and Nix systems each get a native route. Raspberry Pi 5 on a 64-bit OS is called out separately because the official arm64 payload is what gets built.

The naming matters more than it looks. The application appears in desktop menus as ChatGPT Community with an icon marked with a blue C, while the package, command and installation identity stay codex-desktop and /opt/codex-desktop. That separation is intentional: the official chatgpt package and this one can coexist on the same machine, and the menu entry tells you which one you launched.

How the build reuses the signed upstream payload

The mechanism is a repackaging pipeline, not a patch set. The Makefile resolves the current package through OpenAI's signed stable APT metadata, builds a codex-app/ tree, assembles the native package for the detected distribution, and installs the newest artifact from dist/. Distribution detection reads /etc/os-release and matches on ID and ID_LIKE, with fallbacks to dpkg-deb, rpmbuild and makepkg if the identifier is inconclusive.

The strongest claim in the README is about integrity: with no ASAR-changing feature enabled, resources/app.asar remains byte-for-byte identical to the official package. That is the design boundary. The Linux additions live outside the asar, which is why the project can describe itself as a distribution rather than a modified client.

The feature helpers are separate Rust crates. The workspace in Cargo.toml lists computer-use-linux, read-aloud-linux, updater and record-replay-linux as members, so the Linux-specific behaviour is compiled as its own components rather than injected into the upstream bundle. The updater is one of those crates, and it is optional: the AppImage path is documented as producing a local AppImage without the native updater.

Three build knobs appear in the Makefile and are worth knowing before you run anything. APP_DIR defaults to ./codex-app, UPSTREAM_DEB is empty unless you set it, and PACKAGE_WITH_UPDATER defaults to 1. MAX_BUILD_THREADS defaults to 0, which the Makefile treats as "no explicit jobs argument" for Cargo.

Installing codex-desktop-linux on Debian, Fedora, Arch or NixOS

Native packages are built from a clone, so the first step is getting the source. The README gives this exact pair of commands.

git clone https://github.com/ilysenko/codex-desktop-linux.git
cd codex-desktop-linux

The recommended installation is a single target that installs build dependencies, resolves the upstream package, builds, packages and installs.

make bootstrap-native

On Debian, Ubuntu, Pop!_OS, Mint and Elementary that produces and installs a .deb. On Fedora and openSUSE it produces an RPM. On Arch, Manjaro and EndeavourOS it produces a pacman package. On Raspberry Pi 5 with a 64-bit OS the same target builds the official arm64 payload. If the dependencies are already present, the README points to make install-native instead, which skips the bootstrap step.

To pick optional features before installing, the documented sequence is two commands, and the README is explicit that the first one only writes the local feature selection and does not build or install anything.

make setup-native
make install-native

Nix users do not clone at all. The README gives a single flake invocation that builds and runs the output.

nix run github:ilysenko/codex-desktop-linux

For atomic desktops and distributions without a native path, the documented route is make build-app followed by make appimage, which produces a local AppImage without the native updater. Build tools require Node.js 20 or newer, npm, Python 3, curl, gpgv, dpkg-deb, tar, make and a C/C++ toolchain, with Rust used for the updater and the enabled native feature helpers. The README states that make bootstrap-native installs or guides you through these requirements.

The anonymous launch count and how to turn it off

The launcher sends at most one anonymous usage event per UTC day to a public GoatCounter dashboard, with the fixed path /app-launch. The README is unusually precise about what is and is not included: no application activity, account or machine identifier, version, architecture, package format, language, screen size or referrer. GoatCounter derives an aggregate country from the network request. Every installation sends the same fixed, non-identifying User-Agent so the request is not discarded as bot traffic.

The request is silent. A missing curl, a blocked request or any other error never delays the application and produces no output. The stated purpose is to help the community decide whether maintaining the distribution is useful, which is a reasonable justification for a project that depends on upstream churn.

Disabling it is one environment variable in front of the command.

CODEX_LINUX_DISABLE_USAGE_REPORTING=1 codex-desktop

If your environment blocks outbound requests by default, nothing breaks. If you object to the count on principle, the switch is documented and takes effect per launch.

Where codex-desktop-linux stops being the right tool

Two applications, one profile. The README warns that the official chatgpt package and this one may coexist but both intentionally use the upstream Codex user profile, and that you should not run them at the same time because the upstream single-instance lock may route the second launch into the process that is already running. That is a real operational constraint, not a footnote: if you keep the official package installed for comparison, you have to be disciplined about closing one before opening the other.

The AppImage path has a sandbox caveat. AppImage never adds --no-sandbox automatically, and if your distribution disables unprivileged user namespaces, the README directs you to use the native package or follow the sandbox guidance in the troubleshooting document. On distributions that restrict unprivileged namespaces by default, the AppImage is the wrong choice.

There is no documented rollback. The README covers uninstall in detail, including the per-distribution package manager commands and the systemctl --user disable --now codex-update-manager.service step for a service left behind by an older or manual installation, but it does not describe reverting to a previous build. If you need to pin a version and step back, the README is silent on how.

Only the latest signed stable OpenAI Linux package is supported. If you need to stay on an older upstream release, or you are on an architecture other than amd64 or arm64, this distribution does not cover you. The README also notes that old .dmg, DMG= and CODEX_DMG_* inputs are intentionally unsupported, so any build recipe you carried over from a macOS-oriented workflow will not work here.

codex-desktop-linux compared with installing the official .deb

The obvious alternative is the official package itself, and the difference is mostly about packaging rather than features. OpenAI ships a signed Linux .deb. If you are on Debian or Ubuntu and that package satisfies you, installing it directly gives you a vendor-signed artifact with a vendor-supported install path, and you skip the Node.js, Rust and C/C++ toolchain requirements entirely.

What you give up by doing that is the rest of the matrix. There is no RPM, no pacman package, no Nix flake output and no AppImage from the upstream .deb alone. codex-desktop-linux exists to fill exactly that gap, and it does so by resolving the same signed upstream payload through the stable APT metadata rather than by maintaining a divergent codebase. The README's byte-for-byte asar claim is the project's way of saying the gap is packaging, not behaviour.

The trade-off is trust placement. With the official .deb you trust OpenAI's signature and their install path. With this project you trust the build pipeline that verifies and repackages the payload, plus whatever optional Linux features you enable. If you provide a local package via UPSTREAM_DEB, the README states that signed repository discovery is skipped and the caller is responsible for the package's origin, though the file is still checked for package name, architecture, control metadata, payload completeness and SHA-256 recording.

For Nix and NixOS users the comparison is starker. There is no official .deb workflow that fits a declarative system, and the flake output is the documented way in.

Maintenance, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-14, which is the same day as the current date. That is as current as a repository can be, and it is the only maintenance signal available here: no releases were retrieved, so there is no changelog history to read through. CHANGELOG.md exists at the top level, and the README links CONTRIBUTING.md and AGENTS.md for contributors and coding agents respectively.

The licence is MIT. That covers this project's own build tooling, packaging scripts and Rust feature crates. It does not relicense OpenAI's application: the upstream Electron runtime, bundled codex and rg binaries, plugins, locales and Owl metadata are reused directly from the signed upstream payload and remain under whatever terms OpenAI applies to them. MIT on the packaging layer is not a statement about the redistributed application, and nothing here should be read as legal advice about redistribution.

Upgrade cost is dominated by upstream churn. Because only the latest signed stable OpenAI Linux package is supported, a new upstream release means rebuilding, and the Makefile has targets for that: update, rebuild, rebuild-install and rebuild-next, with REBUILD_REPORT_DIR defaulting to ./dist-next/rebuild. The optional updater crate, which is included by default via PACKAGE_WITH_UPDATER=1, is the mechanism for staying current without manual rebuilds, and it is explicitly absent from the AppImage path. Uninstalling disables the user update service, so the updater is treated as part of the package rather than a separate daemon you manage by hand.

Editorial conclusion

Adopt it if you want OpenAI's Linux ChatGPT payload in a distro-native package with optional Linux features and you are willing to build from a clone. Skip it if you need a signed vendor artifact, a supported AppImage sandbox story, or any rollback path, because the README documents none. Verify first that your machine is amd64 or arm64, that Node.js 20 or newer is present, and that you are not running the official chatgpt package at the same time.

Frequently asked questions

Official sources

1. ilysenko/codex-desktop-linux on GitHub
2. Issues
3. License: MIT
4. README