Jack Allison · Writing

A launcher, not a fork: running other models through a signed binary you never touch

Claudex runs Codex GPT models through the Claude Code terminal interface. The obvious way to build that is to fork the client and patch it. The obvious way is also the one that breaks on every release and asks users to run something unsigned.

28 July 2026 · 4 min read · Claudex

The constraint that decided the architecture

Claude Code ships as a signed executable. If you want it to talk to a different model provider, the direct approach is to fork it, patch the request path and distribute your build.

That approach fails in three ways at once. Your patch has to be reapplied every time upstream releases, so you are permanently behind. Your build is no longer the signed one, so every user has to accept an unsigned binary from a stranger. And you have taken on responsibility for the behaviour of a large program you did not write.

So Claudex never touches the binary. It is a launcher. The signed executable on disk is the one the vendor shipped, byte for byte, and it stays that way.

How the redirection actually works

Instead of patching, Claudex starts an isolated Claude Code profile and points it at a local bridge. The bridge is a CLIProxyAPI instance bound to 127.0.0.1:8318 and guarded by a generated key. Every model request goes through that loopback bridge to the user's own authenticated Codex account.

Two properties fall out of this that are worth stating plainly. The bridge is loopback only, so nothing on the network can reach it. And the account is the user's own: Claudex is not a proxy service with a key of its own, it is a piece of local plumbing between two things the user already has.

Authentication reuses the Codex desktop or CLI session already on the machine, including live detection of an account switch. The official Codex browser login opens only when it is genuinely needed. The alternative, asking users to paste an API key into a third party tool, would have undone the entire point.

The status line has to be honest

A compatibility layer is judged on whether the interface still tells the truth. Two numbers matter most in a long session, and both are easy to get wrong.

Context accounting is the first. A wrapper that loses track reports a confident zero and then the session dies mid task. Claudex keeps stable accounting and compacts automatically near 280k tokens, so the number in front of you is the number.

Usage limits are the second. It reports the real 5 hour and 7 day Codex windows in the status line and via /usage-limit, and shows the detected subscription tier in the startup banner. Guessing at someone's remaining quota is worse than not showing it, because a wrong reassurance costs them the work in flight.

The model aliases exist for the same reason: Sol for the hardest reasoning, Terra for balanced implementation, Luna for fast bounded work, and Solplan, which plans with Sol and hands implementation to Terra automatically. Native agent activity labels look like "Terra (high) - Audit JSON parser bugs", so the interface still says what is happening rather than becoming opaque because the model underneath changed.

Install is a supply chain, so treat it as one

Claudex installs with one command, which means the install path is a supply chain and deserves the same scrutiny as the rest. The website bootstraps resolve the latest stable GitHub release without going through the rate limited GitHub API, then validate the published SHA-256 digests from SHA256SUMS before anything runs.

The archive handling assumes hostility. Tampered archives are rejected, and so are archives containing symlinks or path traversal entries, which is the classic way an installer is talked into writing outside its own directory. Self updates apply the same SHA-256 verification in the background rather than trusting that an update is fine because it arrived through the same channel as the last one.

For people who would rather not pipe a script to a shell at all, it is also on Homebrew and Scoop.

Diagnosing it without printing secrets

Credentials live under ~/.config/claudex and are never printed, logged or committed. That creates the usual support problem: when something is broken you need to know the state of the thing you have deliberately made invisible.

claudex --doctor reports bridge health, proxy version and auth state without printing tokens. It answers is the bridge up, is the proxy the version I expect, am I authenticated, which is almost always enough to locate the fault, and none of the answers are worth stealing.

It is about 13,000 lines of Bash, PowerShell and Node kept in strict behavioural parity across macOS, Linux, Windows and WSL, and it is MIT licensed. It is an independent community project, not affiliated with or endorsed by OpenAI or Anthropic.

More writing