Codex App Transfer: a local Rust gateway for pointing Codex at Kimi, DeepSeek or GLM

The gap between Codex and third-party inference providers

Codex speaks the OpenAI Responses API. Most cheap or regional inference providers speak Chat Completions, and a few speak something else again. The two wire formats are not interchangeable: tool calls, streaming event names, and the way conversation history is referenced all differ. Codex App Transfer exists to sit between them. It is a desktop application, written in Rust with a Tauri 2.x frontend, that listens on your machine and rewrites requests on the way out to whatever provider you selected. The README describes it as a lightweight desktop configuration and forwarding tool aimed at the OpenAI Codex APP, and the stated goal is that Codex can use third-party chat/completions inference services without Codex itself being modified. The audience is therefore narrow and specific: developers who already have a Kimi, DeepSeek, Zhipu GLM, Bailian or similar key, and who want Codex's interface on top of it. Anyone happy with an official OpenAI plan is not the target.

How the translation layer handles tools, reasoning and compaction

The mechanism is a local HTTP gateway. Once forwarding is started, Codex talks to 127.0.0.1:18080, and the gateway converts the Responses API request, streaming or non-streaming, into the upstream protocol. That upstream is not limited to Chat Completions: the README lists Gemini Native via :streamGenerateContent, Gemini CLI OAuth through Cloud Code Assist, Anthropic Messages at /v1/messages, Grok Web, and a passthrough Responses mode. The interesting work is not the URL rewriting but the state that Codex assumes the server keeps. Multi-turn tool conversations, previous_response_id history replay, autocompact expansion and reasoning_content injection are all reconstructed by the proxy, because a Chat Completions provider has no concept of previous_response_id. Remote compaction is handled on two tracks: the older /responses/compact endpoint and a newer remote compaction v2 path where a normal streaming /responses request carries a compaction_trigger marker and the response returns a single compaction item. The README records that the newer path previously failed with expected exactly one compaction output item, fixed under MOC-198. Reasoning display is another place where the proxy has to guess at client behaviour: reasoning deltas are emitted on the summary channel only, after an earlier attempt to also emit a content channel caused the same thinking block to update twice and flicker during streaming. That is a design trade-off, not a clean abstraction. The proxy is emulating a stateful protocol on top of a stateless one, and each Codex release can shift the assumptions.

Installing it and pointing Codex at a provider

The repository does not document a one-line install. Builds are published as releases on GitHub, and the README points readers there; the Makefile confirms that three-platform releases are produced by GitHub Actions rather than locally. If you want to build the macOS app yourself for testing, the Makefile exposes a single target that installs frontend dependencies, builds the frontend, runs the Tauri bundle step, and copies the result into dist/mac.

make mac-app

The command finishes by printing the path to the built application bundle. That target is explicitly described as being for local self-testing and produces an unsigned .app. For anything else, the documented route is to trigger the release workflow, either by hand or by pushing a tag.

gh workflow run release.yml -f version=<x.y.z>

Once the application is running, the workflow is UI-driven rather than command-line. You add a provider, give it the API key, and map an OpenAI model name such as gpt-5.5 or gpt-5.3-codex to the provider's real model ID. After you enable a provider, the README states that the Codex model selector shows entries in the form <provider> / <real-model>. Starting forwarding makes Codex communicate with 127.0.0.1:18080. Closing the window does not quit the application; it minimizes to the system tray, and the README says you must right-click the tray icon and choose exit to stop it fully. Keep that in mind the first time you wonder why the port is still occupied.

Provider coverage is wide on paper and thin in testing

This is the limitation that matters most, and the project states it prominently rather than burying it. Only Kimi For Coding and Xiaomi MiMo on the Token Plan have completed end-to-end testing on real hardware. Every other built-in Chat Completions provider, a list that includes DeepSeek, Kimi from Moonshot, Xiaomi MiMo Pay for Token, Zhipu GLM and GLM Coding, GLM via Z.ai and BigModel, Alibaba Cloud Bailian, MiniMax, OpenCode Go, WorkBuddy and QoderWork CN, is covered only by unit tests plus occasional user reports. The README asks users to donate API keys for testing, promising they will be used only for that purpose. That is an honest disclosure and also a warning: if you adopt this with DeepSeek, you are running on a path the maintainers themselves have not regression-tested over time. A second failure mode is inherent to the approach. Third-party chat models do not follow GPT's lark grammar for apply_patch, so they produce malformed V4A patches: doubled @@ markers, missing + signs on added files, byte-mismatched context, missing Begin and End Patch envelopes, and multiple non-contiguous hunks without @@ separators. The project adds a repair layer that restores patches against a whitelist, reading the file from disk to align anchors and inserting bare @@ separators only when the split point is unambiguous. Anything unknown is passed through untouched, so Codex reports the error and the model can correct itself. That is a reasonable policy, but it means patch reliability still depends on the upstream model's formatting discipline.

How it differs from routing through a generic proxy

The obvious alternative is a general-purpose LLM proxy that exposes an OpenAI-compatible endpoint and lets you repoint the base URL. Those tools translate request and response shapes and stop there. Codex App Transfer does more, and the difference is exactly the stateful parts: previous_response_id replay, autocompact expansion, reasoning channel selection, the phase field that makes Codex collapse a completed turn's thinking and tool calls into a single Worked for Ns block, and the custom_tool_call to function_call bridge that keeps the apply_patch diff UI working. A generic proxy will forward your JSON faithfully and then Codex will show a broken tool loop, because nothing reconstructed the history the client assumed the server had stored. The trade-off runs the other way too: a generic proxy is not tied to one client's release cadence, and it does not need a repair layer for a patch format it never touches. Codex App Transfer also bundles features that have nothing to do with protocol translation, such as injecting background themes into the Codex Desktop Electron client over the Chromium DevTools Protocol, and a usage panel that shows quota, balance, context breakdown and token rate for a whitelist of providers. Those are conveniences, not reasons to choose the tool, and the README notes that theme injection is best-effort and fails when the debug port is unavailable.

Licence, build requirements and the cost of tracking Codex

The project is MIT licensed, which is permissive and places few obligations on you beyond retaining the notice. The Cargo.toml declares the workspace package as MIT, and LICENSE.txt sits at the repository root. Nothing here suggests a separate commercial tier or a contributor licence agreement, but licence text is not legal advice and you should read LICENSE.txt yourself before redistributing a build. The toolchain requirement is real: rust-version is 1.85, the edition is 2021, and the workspace is split across crates for http, registry, proxy, adapters, codex_integration, conversation_export, gemini_oauth, qoder_auth and usage_tracker, plus src-tauri and xtask. Two further crates, session_cache and update, are listed as commented-out members to be enabled in later phases, which tells you the refactor is still in progress. The upgrade cost is the part to weigh honestly. This gateway exists to satisfy a client that changes: the README documents fixes tied to specific Codex behaviours and versions, including reasoning channel handling and compaction protocol changes. Every Codex update is a chance that a translation path drifts. The release history shows frequent patch releases in mid-2026, and the last push to the repository was on 2026-09-14. Budget for upgrading the gateway alongside Codex, not independently of it.

Editorial conclusion

Adopt it if you already pay for a Chat Completions provider and want Codex to use it without patching Codex itself, and if you accept that only Kimi For Coding and Xiaomi MiMo Token Plan are documented as tested end to end. Do not adopt it if you need a supported, vendor-backed integration, or if you are not willing to read the log panel when a provider misbehaves. Before committing, verify three things on your own machine: that your provider's model IDs map correctly in the model mapping UI, that apply_patch produces a renderable diff rather than a malformed V4A patch, and that the tray process really survives closing the window on your platform.

Frequently asked questions

Official sources

1. Cmochance/codex-app-transfer on GitHub
2. Issues
3. License: MIT
4. README
5. Releases