Codex++ 2.0 replaced tweaks with a menu bar helper you must sign with your own Apple identity

What changed between 1.x tweaks and the 2.0 helper

The 2.0 release is a rebuild, not an increment. The README states that Codex++ 2.0 replaces the 1.x tweak system, which now lives on a `legacy-1.x` branch, with a signed menu-bar helper. The operative sentence is short: 1.x tweaks do not load in 2.0.

The shape of the thing changed accordingly. The old model was a tweak system applied to the app; the new one is a helper that owns patching, connection status, recovery controls and links to the project, living outside the ChatGPT desktop app. The app itself is `ChatGPT.app` with bundle ID `com.openai.codex`, which the README says was verified on the author's machine. The helper validates that identity and migrates a stale `Codex.app` path to the new app.

On the security posture, the README is specific rather than vague. The signed main-process patch hosts renderer Extensions through Electron's in-process `webContents` API, and it opens no DevTools and no extension-control network listener. The helper never force-quits the app.

For anyone upgrading, the README gives the removal step first, because 2.0 will not patch an app still carrying a 1.x modification:

Removing 1.x before 2.0 will patch anything

The upgrade instructions are two commands' worth of caution. Before installing 2.0, quit ChatGPT and remove 1.x:

codexplusplus uninstall

That restores the app when it can. Adding `--purge` also deletes 1.x tweaks, config, logs and backups.

The constraint that follows is the important one. The README says 2.0 patches only an app that still carries OpenAI's signature, so if the uninstall cannot restore it, you must reinstall ChatGPT from OpenAI first. In practice that means a partially removed 1.x can leave you unable to patch at all until you reinstall the desktop app.

Building it requires a Developer ID, not just Xcode

Running from source needs macOS 14 or later, Swift 6 with the Xcode command-line tools, and Node with its Node-API development headers to build the native browser adapter. Homebrew header locations are discovered automatically, and `CODEXPP_NODE_INCLUDE` points the build at another Node installation. The built helper uses ChatGPT's bundled Node runtime, so it needs no separate Node installation at run time.

./scripts/build-app.sh
open 'dist/Codex++.app' --args --show-menu

Those two lines are the whole run path. The resulting app lives in the menu bar with no Dock icon and no separate window, using a monochrome rounded eight-spoke icon that follows the supplied logo and adapts to the menu bar appearance.

The build step carries the real constraint. Builds require an installed Apple-issued Developer ID Application signing identity. The build selects it automatically when exactly one is available, and `CODEXPP_SIGNING_IDENTITY` resolves the ambiguity when several are installed. The patcher pins that certificate and rejects self-signed legacy pins. For release builds, `CODEXPP_NOTARY_PROFILE` names a `notarytool` keychain profile used to submit and staple the helper.

Why there is no prebuilt binary

The distribution model is stated in bold in the README: Codex++ is released as source code for developers who own an Apple-issued Developer ID Application identity. The reason is keychain partitioning. The patched ChatGPT bundle must be signed locally with the same identity as the locally built helper in order to preserve its stable Keychain partition.

The consequence follows directly. The README says not to redistribute a prebuilt helper, because another user will not possess its private signing identity and the patcher will correctly refuse to use a different signer. `scripts/release-source.sh` produces the versioned source archive and checksums from a clean, tagged commit.

So the cost of adopting this is not an install command, it is an Apple-issued Developer ID Application identity plus a local build. Users compile and sign the helper themselves.

Updates are a source release verified by SSH signature

Because every user builds and signs with their own identity, an update is a source release rather than a binary. The helper checks about once a day, and on demand through Codex++ then Check for Updates, by downloading `release.json` and `release.json.sig` from the latest GitHub release.

The verification rules are strict and worth reading. The signature must be an SSH signature in the `codexpp-release` namespace from the release key listed in `Sources/CodexPPCore/Resources/release-signers`, which is compiled into the helper you built. The README states that checksums published next to a release are not trusted on their own. The manifest must name this repository, its own tag and artifact, and a newer version, with no downgrades allowed.

After that the helper downloads the source tarball, requires its size and SHA-256 to match the signed manifest, extracts it into an empty folder under `~/Library/Application Support/CodexPP/Updates/`, and builds it with `scripts/build-app.sh` using your toolchain and your pinned Developer ID. The Sparkle build is cached across releases. The menu then offers Restart to Update Codex++, and the staged helper swaps the bundle in place with one atomic exchange, keeping `.Codex++.previous.app` beside it. If the new helper does not confirm it is running, it swaps back and relaunches the old one.

Turning off Update Automatically limits checks to manual ones.

One Extensions system, with a stated compatibility boundary

The README is unambiguous that there is one Extensions system, and that renderer packages are supported while packages for older main-process or native APIs need adaptation. A remote catalogue is future work.

The plumbing is documented in enough detail to be checkable. Appshots keep working through the bundled OpenAI-signed `cua_node` runtime: Codex++ accepts capture requests only from the trusted `app://-` main frame, starts the packaged headless CUA launcher, requests a snapshot over the service's native pipe, and maps the result into existing Appshot renderer events. It does not launch a second Electron app, expose a CDP port, or change the computer-use service and its authentication policy.

Settings integration goes through an adapter that registers Extensions in the shared native navigation list, sidebar, Settings search and Cmd-K menu, using the app's own Settings page, section, card, row, button and switch components with its React instance. The first restart from the helper stages, verifies and installs Extensions support; later launches start the helper and its loopback connection automatically.

One bundled extension shows the intended shape. `better-browser` enables macOS AutoFill in editable in-app browser fields through a narrow native bridge and the clicked frame with the existing context menu. It requires you to build the current helper and restart ChatGPT through Codex++ to install that bridge before enabling the extension, which is the general install path every extension follows: new extensions start disabled, and reinstalling the same ID replaces its package.

Where this is the wrong tool

The gating requirement is unambiguous. Without an Apple-issued Developer ID Application identity there is nothing to build, and without macOS 14 or later there is nothing to run it on. That rules out Linux and Windows hosts, as well as teams that have deliberately moved developer machines off Apple signing.

The second wrong case is expecting a stable plugin API. The README states that packages for older main-process or native APIs need adaptation, and that this is a patch on someone else's Electron application. If the upstream app changes its internals, the patch has to change with it. The v1.x to 2.0 break, where no 1.x tweak loads in 2.0, is a concrete example of that cost.

The third is treating it as a distribution channel. You cannot hand a colleague a build and have it work, because the patcher refuses a different signer by design. Adoption is per-machine and per-identity.

The repository does carry a SECURITY.md, a CHANGELOG.md, THIRD-PARTY-NOTICES.md, a `vendor/` directory, `Tests/`, `docs/` and an `examples/quiet-focus/` sample, and it is not archived with the last push on 2026-10-14 alongside the 2.0.0 tag the same day. What it does not document is the exact set of ChatGPT app versions the current patch supports, so verifying that compatibility against your installed build is the first thing to check.

Editorial conclusion

Adopt Codex++ 2.0 only if you develop on macOS, hold an Apple-issued Developer ID Application identity, and need to extend the Codex desktop app with your own renderer Extensions. Do not expect a downloadable installer: the distribution model is a signed source archive, and the patcher refuses a signer that is not the certificate you pinned. Before installing 2.0 over 1.x, quit ChatGPT and run `codexplusplus uninstall`, adding `--purge` to remove 1.x tweaks, config, logs and backups, and reinstall ChatGPT from OpenAI first if the uninstall cannot restore a signature that still carries OpenAI's mark.

Frequently asked questions

Official sources

1. b-nnett/codex-plusplus on GitHub
2. Issues
3. License: MIT
4. README
5. Releases