codex-chatgpt-web: run Codex tasks through a signed-in ChatGPT web session

The gap codex-chatgpt-web fills between Codex and the ChatGPT web tiers

Codex has its own model picker and its own usage limits. ChatGPT Web has a separate set of model tiers, and a Pro subscription exposes efforts that the Codex picker does not offer. codex-chatgpt-web exists to put the second set inside the first: the README describes it as a way to use ChatGPT Web, including Pro, as native Codex models while keeping the original task UI, context lifecycle, streaming, tracing and tool presentation.

The intended user is someone who already works in Codex and holds a ChatGPT account, including Free and Go accounts, which the README says get a single picker entry called ChatGPT Web, Luna. Accounts that expose the reasoning selector keep Instant, Medium, High, Extra High and Pro, as the subscription allows. That mapping is the whole product. It is not a general ChatGPT client, and it is not a way to get more quota: it changes which model answers a Codex task, not how much of anything you are entitled to.

How the bridge works: Responses, SSE and one Temporary Chat per task

The architecture is small enough to draw in a few lines. Codex sends a Responses request over SSE to a local process, codex-chatgpt-web, which drives an embedded browser pointed at ChatGPT, and the results flow back into the same Codex task as native UI, context, images, tracing and tool lifecycle events. The README's diagram shows exactly that loop.

The routing rule matters more than the diagram. Only the selected model task is routed through a task-bound ChatGPT Temporary Chat. Codex keeps the native task, the context lifecycle, the UI and the tool harness; the bridge does not take them over. Sequential messages reuse the same task-bound Temporary Chat, and at the context boundary a retained agent writes the checkpoint before Codex starts a clean chat. If that chat was already closed, the README says canonical Codex history supplies the fallback. That is a reasonable design for continuity, but it also means the quality of a resumed session depends on a checkpoint written by the agent rather than on a server-side thread.

The README is explicit that Temporary Chat is a privacy mode, not anonymity and not local inference. Prompts are still processed by OpenAI and remain subject to the account's settings and the Temporary Chat policy. Anyone reading "temporary" as "nothing leaves my machine" has the wrong model of this tool.

Installing the launcher and running a first task

The supported path is the desktop launcher, which the README describes as cross-platform for macOS, Windows and Linux, and which owns sign-in, model setup, MCP guidance, health checks, diagnostics and up to five visible task-bound browser tabs. On macOS or Linux the install is a single script fetched from the latest release.

curl -fsSL https://github.com/miuuyy/codex-chatgpt-web/releases/latest/download/install-launcher.sh | sh

On Windows the equivalent is a PowerShell one-liner.

irm https://github.com/miuuyy/codex-chatgpt-web/releases/latest/download/install-launcher.ps1 | iex

After that the README lists three checks inside the app: sign in directly in the launcher's embedded ChatGPT browser, run the browser smoke test, then press Install models, restart Codex once and pick a ChatGPT Web model. The launcher keeps login pages and identity-provider windows inside its own private browser profile, and the README states no session is copied between browsers. It also states the packaged launcher needs no model API key, no installed Chrome or Chromium, no system Node or Bun, and no project-managed browser download.

If you prefer to run from source, the README gives this path, which requires Bun 1.4.0 and installs locked dependencies before opening the app.

git clone https://github.com/miuuyy/codex-chatgpt-web.git && \
cd codex-chatgpt-web && \
bun run app

To update or repair an existing installation, the README says to quit the launcher and run the same install command again; it replaces the application and embedded runtime while preserving the ChatGPT profile and launcher configuration.

Browser-only versus full harness, and the connector trap in full mode

The two modes differ in whether ChatGPT can call back into the Codex task. In browser-only mode there are no local Codex tools and Codex shows a warning about that. In full harness mode, every listed effort including Pro gets the active task's filesystem, shell, images, approvals and configured tools and apps, delivered over MCP through the official OpenAI tunnel-client. The README notes the tunnel is outbound: no public IP, no inbound port, no router forwarding.

Setup for full mode is the part most likely to go wrong, and the README spends a warning on it. You create a new connector named Codex Native2 with permissions set to Allow all actions, and you leave any older Codex Native connector untouched rather than renaming or refreshing it. The stated reason is that ChatGPT caches the public MCP contract by connector identity, and that Allow low-risk actions blocks commands and patches before they reach the Codex harness. If you half-follow that instruction, the failure is silent at the ChatGPT end and invisible in Codex.

The remaining steps are: open MCP in the launcher, create a Tunnel and a regular API key on the same OpenAI account that will use the connector (the README says creating the key is free and consumes no model API credits), paste the Tunnel ID and API key, press Connect harness, then in ChatGPT settings enable Developer Mode, create a new connector using Tunnel, select that exact Tunnel, set Authentication to None and name it exactly Codex Native2.

Fail-closed behaviour is the project's best design decision

The README states that missing models, tools or a changed ChatGPT UI produce explicit errors instead of silently switching route or capability. For a tool that sits between two products the author does not control, that is the right call. ChatGPT's web UI changes without notice, and a bridge that quietly falls back to a different model or drops a capability would produce results you cannot attribute to anything.

The cost is that a ChatGPT UI change can break the bridge outright rather than degrade it. The README points to end-to-end coverage in docs/release-validation.md and ships a set of smoke scripts in package.json, including smoke:codex, smoke:cancel, smoke:interrupt and smoke:subagents, which suggests the maintainers treat these paths as things that need re-verification rather than as stable interfaces. Version numbers in the repository are also ahead of the newest listed release, with package.json at 5.0.6 and the most recent release noted as v4.0.5, so check which artifact you are actually installing.

Where codex-chatgpt-web is the wrong tool

It is unofficial, and the README says so directly: users remain responsible for complying with applicable OpenAI terms and workspace policies. If your organisation requires a supported integration path with a vendor behind it, this is not that, regardless of how well the bridge works.

It also depends on a signed-in browser session that the launcher owns. That is a real operational constraint on a headless server, in a container, or on any machine where nobody can complete an interactive login and re-authenticate when the session expires. The README documents no headless path and no API-key-only mode, because the whole point is to use the web session instead of the API. And if what you actually want is a supported web interface to Codex, this is not it: it is a bridge that makes ChatGPT Web answer Codex tasks, not a browser version of Codex.

How it compares with calling the model API from Codex directly

The obvious alternative is to point Codex at the provider's model API with a key, which is the documented, supported route and works headlessly on a server with no browser anywhere. The difference in approach is where the session lives. An API integration authenticates with a key you provision and rotate, and it bills against API credits. codex-chatgpt-web authenticates with a browser profile you sign into by hand, and it uses the ChatGPT subscription you already have instead of API credits, which is the entire reason someone would accept the browser dependency.

That trade has consequences beyond convenience. The API route gives you a stable contract that does not change when a web UI is redesigned. The bridge gives you the model tiers your subscription exposes, including Pro, at the cost of a component that can break when ChatGPT's front end moves. If your workload is unattended and long-running, the API route is the one that will still be running next month.

Licence and the real maintenance cost

The repository is MIT licensed, with a LICENSES/ directory and a licenses script that generates third-party notices including the launcher, which is the usual shape for a project that bundles a runtime. MIT is permissive and places few obligations on you beyond retaining the notice, but the bundled launcher and embedded runtime bring their own components, so read the generated notices rather than assuming the top-level licence covers everything. That is a description of the repository layout, not legal advice.

On maintenance, the last push was on 2026-08-29, and the newest listed release, v4.0.5, carries the same timestamp. The upgrade path is unusual in a way that lowers cost: the README says re-running the install command replaces the application and embedded runtime while preserving the ChatGPT profile and launcher configuration, so updates do not force a fresh sign-in. The recurring cost is not the upgrade, it is the re-verification after ChatGPT changes something, which is why the smoke scripts exist.

Editorial conclusion

Adopt it if you already run Codex and want the ChatGPT Web tiers, including Pro, inside the native task UI without provisioning a model API key. Skip it if you need a supported, documented integration path, or if you cannot keep a launcher-owned browser profile signed in; the README states this project is unofficial and that prompts still go to OpenAI under the account's Temporary Chat policy. Before committing, run the browser smoke test and the health checks in the launcher, and confirm your signed-in account actually exposes the effort selector you need, because the launcher detects available models at setup time.

Frequently asked questions

Official sources

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