Codex++: a launcher that layers provider switching onto the Codex desktop app

The gap Codex++ fills between the official Codex app and third-party providers

The official Codex desktop app assumes you are talking to OpenAI. Codex++ is built for people who are not, or who are not only. Its stated purpose is to be an external launcher and management tool for the OpenAI Codex / ChatGPT desktop app, adding provider switching, protocol conversion, session management and interface enhancements. The audience is developers who want to route Codex through an aggregated provider, a relay, or a mix of official login and a custom API endpoint, and who do not want to edit the application bundle to do it.

The design decision that matters is where the modification happens. The README states that Codex++ does not modify the official app's app.asar and does not write patch files into the installation directory. That is a deliberate boundary. Patching app.asar is the usual shortcut for this kind of tool, and it breaks on every upstream update. Codex++ instead attaches from outside, which means an official app update does not automatically invalidate the setup, and an uninstall does not leave a modified bundle behind. The cost is that everything has to go through the browser layer and a local service, which is a narrower channel than direct code injection.

How the launcher, the DevTools Protocol and the local service fit together

The mechanism named in the README is the Chromium DevTools Protocol plus a local helper service. The desktop app is a Chromium shell, so it exposes a debugging interface. Codex++ connects to that interface and drives the parts of the UI it needs, while the helper service handles the work that does not belong in the page: provider configuration, protocol conversion, session state.

The workspace layout in Cargo.toml reflects that split. There are two library crates, codex-plus-core and codex-plus-data, and two applications, codex-plus-launcher and codex-plus-manager. The launcher is the entry point that starts the official app silently and loads saved configuration and enhancements. The manager is the separate Tauri application for configuring providers, models, tool plugins, sessions, enhancements, scripts, updates and diagnostics. Data persistence is SQLite through rusqlite with the bundled feature, and the dependency list includes aes-gcm, which suggests credentials are encrypted at rest rather than stored in plain text. The README does not spell out the encryption scheme, so treat that as an inference from the dependency list, not a documented guarantee.

Protocol conversion is the other half. Providers do not all speak the same API shape, and the feature table lists both Responses and Chat Completions as supported modes. That conversion is what lets a provider that only offers one of the two shapes work with a client that expects the other.

Installing Codex++ and running it for the first time

The README points to GitHub Releases for installers, with separate packages per platform: a Windows x64 setup executable, and macOS DMG images for Intel and Apple Silicon. There is no package manager step documented, so installation is a download and run.

The macOS artifacts follow this naming pattern:

CodexPlusPlus-*-macos-arm64.dmg
CodexPlusPlus-*-macos-x64.dmg

The Windows installer is named CodexPlusPlus-*-windows-x64-setup.exe. On Windows the installer creates desktop and Start menu shortcuts. On macOS the DMG installs /Applications/Codex++.app and /Applications/Codex++ 管理工具.app.

After installation there are two entries. Codex++ starts the official desktop app silently with saved provider configuration and enhancements loaded. The management tool is where configuration happens. The README gives an explicit first-run order: open the management tool first, confirm the application path and running state, then configure providers and enhancements, and only then launch from the Codex++ entry. Following that order matters because the launcher reads saved configuration at startup. If you launch first and configure afterwards, you are testing an unconfigured run. The README does not document a rollback procedure, so if a configuration change leaves the app in a bad state, the recovery path is not described.

What the provider and model configuration actually covers

The feature table in the README is the most concrete part of the documentation. Provider configuration supports four modes: official login, official login mixed with an API, pure API, and aggregated providers. The mixed mode is the interesting one. It means you can keep the official session for some traffic and route other traffic through a custom endpoint, rather than choosing one or the other globally.

On the model side, the table lists per-model context windows, automatic compaction thresholds, and a model_catalog key. It also lists model testing, model listing, a Provider Doctor diagnostic, and import from cc-switch and from links. Provider Doctor is the piece worth calling out: it implies the project expects provider configuration to fail in ways that are not obvious from a failed request, and gives you a diagnostic surface for that.

The repository also ships AGENTS.md, CHANGELOG.md, CONTRIBUTING.md and a docs/ directory. The README's feature table is truncated, so the full list of enhancement modules is not visible from the README alone. Anyone evaluating the enhancement features should read docs/ directly rather than relying on the README summary.

Where Codex++ is the wrong tool

If your only requirement is signing into the official Codex app and using it, Codex++ adds a process, a local service and a configuration surface for no benefit. The README's own first-run flow requires you to confirm the app path and running state before anything works, which is friction that a plain install does not have.

The bigger limitation is the attachment mechanism itself. Anything built on the Chromium DevTools Protocol depends on the host app continuing to expose that interface and on the UI structure staying recognisable. An upstream Codex release that changes either can break Codex++ in ways the project cannot prevent, because it does not control the host. The README does not describe a compatibility policy or a supported version range for the official app, so there is no documented way to know in advance whether a given Codex build will work.

There is also a platform gap in the documentation. The installers listed are Windows x64 and macOS (Intel and Apple Silicon). The README does not list a Linux package, even though the repository is Rust and could in principle be built from source. If you are on Linux, the README gives you nothing to follow.

How Codex++ differs from patching the app or using a proxy

The obvious alternative is patching the official app directly, editing app.asar or dropping files into the installation directory. That approach can reach deeper, because it changes the application code rather than driving it from outside. It also breaks on every update and leaves the installation in a modified state that is hard to reason about later. Codex++ takes the opposite trade: less reach, but the official bundle stays untouched and updates do not automatically wipe your configuration.

The second alternative is a network-level proxy that rewrites requests to and from the provider. A proxy is provider-agnostic and works with any client, not just Codex. But it has no visibility into the desktop app's session or UI, so it cannot do session management, model catalog handling or interface enhancements. Codex++ sits between the two: it is client-aware, which a proxy is not, and non-invasive, which a patch is not. The price is that it only works with the one host application it was built for.

Maintenance, upgrade cost and the AGPL-3.0-only licence

The repository is not archived, and the last push was on 2026-08-27, which is recent. The release history shows v1.2.56, v1.2.55 and v1.2.54 landing on 2026-08-27, 2026-08-26 and 2026-08-25 respectively, so releases arrive frequently and in small increments. That is a high-churn pattern. The practical upgrade cost is that you should expect to re-download installers rather than sit on one version, and that a version you pin today may be several releases behind within a week. The workspace version in Cargo.toml is 1.3.0, ahead of the latest release tag, which is consistent with work happening between releases.

On licensing, Cargo.toml declares license = "AGPL-3.0-only" and the repository carries a LICENSE file plus THIRD_PARTY_NOTICES.md. AGPL-3.0-only is a strong copyleft licence with a network-use clause. If you plan to redistribute Codex++ or offer it as part of a hosted service, the obligations are materially different from a permissive licence, and the third-party notices file matters because the dependency list is long. This is not legal advice; read the LICENSE and THIRD_PARTY_NOTICES.md, and get your own review if you intend to distribute it.

One more maintenance note: the README's sponsor table lists a number of API relay services. Those are commercial links, not project dependencies. Their presence tells you who funds the project, not what the software does.

Editorial conclusion

Adopt Codex++ if you already run the official Codex desktop app and want to point it at non-official or mixed providers, or switch between them, without modifying app.asar. Do not adopt it if you are happy with the official login alone, or you need a documented rollback path, since the README does not document one. Before installing, verify the app path and running state in the management tool, check whether your provider speaks Responses or Chat Completions, and read THIRD_PARTY_NOTICES.md alongside the AGPL-3.0-only licence in Cargo.toml.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes