Codex with ChatGPT is a TypeScript bridge that lets the ChatGPT web app plan and review coding work while Codex executes it locally. It trades API keys and reverse proxies for a read-only MCP connection. The tool fits technical teams that already pay for ChatGPT and want planning work off metered API tokens. Treat the maintainers’ “verified end-to-end” status as a claim, not independent proof. Close the open tunnel and routing issues before production use.
| Item | Detail |
|---|---|
| Author / reviewer | Xiang Peng (XP812) |
| Review method | Source and documentation review; no local installation or runtime test |
| Review date | 2026-09-24 |
| Version snapshot | v0.1.3 latest release (published 2026-09-11); last repository push 2026-09-13 |
| License | MIT |
| Stars (snapshot) | 4,128 stars and 438 forks at collection on 2026-09-24 |
| Language | TypeScript |
| Verification level | Observed: source and documentation review only |
| Material unknowns | No independent security audit or benchmark, unproven long-term maintenance commitment, and open tunnel, routing, and connector issues |
what problem this bridge solves
According to the repository, the project targets a specific cost and workflow problem. Teams paying for ChatGPT Plus or Pro leave that web quota idle while their coding agent burns scarce API or Codex tokens on planning and review. The bridge puts the ChatGPT web app in the planner and reviewer role and keeps Codex as the execution layer. The maintainers summarize the design as “ChatGPT thinks, Codex works.”
The documented mechanism is a local bridge called C2C. It runs a loopback HTTP server that exposes read-only Model Context Protocol (MCP) tools to ChatGPT through a Cloudflare tunnel. The README says the connection uses OAuth 2.1 with PKCE and one-time pairing codes. It also says the repository is never uploaded and that sensitive files such as .env files and keys are denied by default, with a .c2cignore file for extra rules. Those are maintainer claims about the design, and this review did not reproduce them.
who should consider it, and who should not
This project fits a fairly narrow profile: a technically capable founder, engineering lead, or operations manager whose team already runs Codex locally, already pays for ChatGPT, and wants to reduce metered token use without standing up a reverse proxy or sharing API keys. The maintainers market the tool broadly, including a one-paste install prompt aimed at non-technical users. The surrounding evidence, from tunnel configuration to HTTP/2 transport switches and OAuth debugging, points to a different operator: someone comfortable with Node.js, command-line tools, and cloud networking.
Do not adopt it as a silent production dependency if you cannot tolerate an unofficial tool inside your development path. The maintainers state plainly that this is an unofficial community project, not affiliated with or endorsed by OpenAI. If your organization requires vendor-backed support, a signed support contract, or an audited security model, nothing in the material reviewed shows those exist here.
what to verify before production
Treat any rollout as a bounded pilot with explicit exit criteria. The open issues in the project’s own tracker are the most useful pre-production checklist:
- Tunnel and DNS correctness: issue #417 reports that Named Tunnel provisioning can report success while the stable hostname still resolves to a different tunnel ID. That can produce Cloudflare 530 / error 1033 even though local checks are healthy. Confirm the hostname actually targets the current tunnel before trusting a green setup.
- Outbound reachability: issue #455 reports that c2c doctor can be green while the ChatGPT project page and connector fail because the outbound route cannot reach ChatGPT or Cloudflare’s verification service. A green local doctor is not proof that the end-to-end path works.
- Connector authorization: issue #450 reports a ChatGPT connector stuck in an indefinite loading state, where the bridge never receives an authorization request and no token is issued.
- Browser dependency: issue #456 requests a fallback when the built-in browser is unavailable, which the maintainers currently restrict. Release notes for v0.1.0 and v0.1.1 state the fully automated workflow targets environments where Codex has access to the ChatGPT in-app browser, and that Linux plus the VS Code Codex extension is not yet guaranteed.
Confirm your network policy as well. The bridge depends on a public tunnel exposing a loopback service, which some security teams will treat as a non-starter regardless of the OAuth design. Decide in advance whether outbound tunnels are permitted, and who signs off on them.
deployment and environment concerns
The documented requirements are Node.js 20 or newer, git, and cloudflared, with pnpm used for install and build. The maintainers ship a c2c command-line interface covering setup, status, doctor, pair, unpair, logs, and stop, plus a Codex Skill that performs most of the setup. Credentials are said to live in the OS app-state directory rather than in the project.
The most operationally important detail is transport. Release v0.1.3 documents a C2C_TUNNEL_PROTOCOL environment variable with the values auto, quic, or http2 for networks that drop idle QUIC connections. Release v0.1.2 documents a C2C_CLOUDFLARED_PATH override for a custom cloudflared binary. If you run this behind a controlled or filtered network, budget real time for tunnel troubleshooting instead of assuming the default path works.
platform limits
The maintainers flag Linux plus the VS Code Codex extension as an unguaranteed combination for the full browser-driven workflow. Teams running Codex on a headless Linux server with the ChatGPT client elsewhere should expect friction. Issue #438 describes exactly that split, where one user ended up running a Linux desktop ChatGPT client to make the flow work.
maintenance signals and release cadence
The repository shows a fast, early cadence: v0.1.0 on 2026-08-30, v0.1.1 on 2026-08-31, v0.1.2 on 2026-09-04, and v0.1.3 on 2026-09-11, with the last push on 2026-09-13 and 13 open issues at collection. The releases read as focused, issue-driven fixes with added regression tests. The maintainers report 164 tests passing in v0.1.2 and 175 in v0.1.3, alongside typecheck and build success. Those figures come from the release notes and were not independently reproduced here.
Rapid early iteration cuts both ways. It signals active maintenance and responsive fixes, which is what you want in a young tool. It also means the configuration surface and reliability behavior can shift between minor versions. Pin the version you pilot, watch the tracker for regressions that touch your environment, and plan upgrades as ongoing maintenance rather than a one-time install.
limitations and unknowns
Several things cannot be established from the material reviewed. There is no independent security audit, no third-party benchmark, and no reproducible performance data attached to this snapshot. The V1 verified end-to-end statement is a maintainer claim about their own path, not evidence that your environment will behave the same way. A high star count shows attention, but it does not show that the project will last or that it fits a regulated workflow.
There is also a governance question. The project is unofficially tied to OpenAI’s models and exposes a local workspace to a third-party web application through a tunnel. Even if the read-only design and file-filtering claims hold, your data-handling review still has to answer whether routing repository reads through the ChatGPT web interface is acceptable for the code you maintain.
A Google Trends signal for “codex” (GB, roughly 100+, week of 2026-09-08) confirms rising general interest in the Codex ecosystem, but it says nothing about this project’s quality or production readiness. Treat it as context, not validation.
evaluation questions and alternatives
If you are deciding whether to pilot, work through these:
- Does the workflow save more in metered tokens than it costs in setup and maintenance time for your team?
- Can your network policy accommodate an outbound Cloudflare tunnel exposing a loopback service?
- Which environments must be supported, and do they include unguaranteed combinations such as Linux with the VS Code extension?
- Who owns upgrades, tunnel troubleshooting, and connector repair when authorization or routing breaks?
- Is an unofficial community tool acceptable, or does the decision require vendor-backed support?
The alternatives depend on what you are optimizing for. If the goal is simply cheaper planning, using ChatGPT directly for design discussion and keeping Codex on execution is the lower-risk route, though it loses the automated review loop and execution records. If the goal is a supported or auditable agent pipeline, a maintained commercial integration or an internal bridge you control is more defensible. This project is itself a custom integration, so treating it as a reference design to study is different from treating it as a product to adopt.
verdict
For a team already running Codex and paying for ChatGPT, Codex with ChatGPT is worth a controlled pilot on one workspace and one machine. It addresses a real cost problem, the maintainers are shipping steady fixes, and the read-only MCP design is a reasonable starting point. It is not ready to be an invisible production dependency: the open tunnel-mismatch and outbound-routing issues, the browser dependency, and the absence of independent verification all argue for keeping it behind a pilot boundary until it survives your own environment over a meaningful period.
Budget for maintenance, not just installation. The realistic cost of this tool is not the git clone; it is the ongoing attention to tunnels, OAuth pairings, transport fallbacks, and version upgrades. If nobody on your team owns that work, the token savings can be eaten by operational time.
If you are weighing a bridge like this for your own team and want help deciding, I work on AI agent deployment and integration at XP812. For this exact problem I would start from your environment: the operating systems and Codex surfaces you use, your network and tunnel policy, which repositories are in scope, and which parts of the workflow cannot change. From there I can help you run a bounded pilot, harden the tunnel and authorization path, or work out whether a supported alternative fits better. To scope that conversation, share your setup and constraints here.
sources
- XiaoDuoYa/codex-with-chatgpt repository
- Release v0.1.3: connector recovery, hidden git_status, and HTTP/2
- Release v0.1.2: structured MCP, safer tunnels, and Windows polish
- Issue #417: Named Tunnel provisioning with a mismatched hostname
- Issue #455: c2c doctor green while ChatGPT project access fails
- Issue #456: Chrome fallback when the built-in browser is unavailable
- Issue #450: connector authorization stuck in a loading state
- Issue #438: remote-control use case running on Linux
- Google Trends: codex (GB)