XiaoDuoYa/codex-with-chatgpt · 30 Aug 2026 · Feature

The Unofficial Bridge Between ChatGPT's Brain and Codex's Hands

Sanne de Vries
Sanne de Vries
Contributing Editor

A community-built read-only MCP bridge lets ChatGPT web handle planning and review while Codex keeps the keys to execution, no API key required.

XiaoDuoYa/codex-with-chatgpt
3.9k stars Velocity · 7d +237 ★/day

The Split-Brain Workflow Is Already Here

For months, developers have been running an ad-hoc experiment across OpenAI’s own forums. They use ChatGPT in the browser to architect and debug, then hand the results to Codex for implementation. One heavy user described the arrangement as a shift where they hardly write code anymore, relying on ChatGPT with a GitHub connector for planning and reserving Codex credits for actual execution [4]. Another forum regular, identified as a community leader, confirmed this has been their go-to approach for complex tasks for quite some time, cycling a Pro model for planning, Codex for implementation, and the Pro model again for review [4]. The thread has drawn over four thousand views, suggesting the split is not a niche habit but an emerging consensus.

XiaoDuoYa/codex-with-chatgpt

The friction is obvious. The handoff between browser chat and IDE agent is fragile. Context does not persist across the boundary. A feature request posted to OpenAI’s community board in April pleaded for a fully integrated local multi-agent coding workflow that would let a planner and executor share the same workspace without manual synchronization [6]. The post received a modest 171 views and no official response, leaving the gap open for an unofficial fix.

That fix is this repository, a community project that treats the ChatGPT web application as the planning and review brain for Codex sessions while stripping it of any ability to execute. Codex keeps full ownership of the shell, the git commits, and the file system. ChatGPT merely reads, suggests, and validates through a read-only bridge.

A Read-Only Bridge Across the Gap

The project’s architecture is best understood as a deliberate separation of concerns between reasoning and execution, a pattern that is hardening across the agentic landscape [8]. The authors divide the world into a control plane and a data plane. The control plane uses OpenAI’s Computer Use channel to exchange tiny structured messages tagged C2C—state transitions such as INIT, PLAN, EXECUTED, REVIEW, DONE. No diffs, no logs, and no file bodies ever traverse this channel. It is a metadata-only handshake.

The data plane is a local loopback HTTP server exposing eight read-only MCP tools: workspace_info, list_directory, read_file, search_workspace, git_status, git_diff, test_status, and execution_summary. ChatGPT pulls exactly the lines it needs through this bridge; it never pushes. The server never sees a write, delete, or shell tool. By construction, the model cannot commit code, modify files, or run commands even if a prompt injection convinces it to try.

To reach the local server from the ChatGPT web interface, the project spins up a Cloudflare Quick Tunnel and protects it with OAuth 2.1. The setup flow generates a one-time pairing code—five-minute TTL, five attempts, rate-limited, destroyed on use—that is the only secret ever rendered in a browser. There are no long-lived API keys to leak, no reverse proxies to maintain, and no repository uploads to a remote vector store. The workspace stays on disk; ChatGPT reads it remotely through a straw.

Security as a Feature, Not a Patch

Most agentic security models rely on permission lists and prompt filters. This project inverts the logic by removing the attack surface entirely. Write tools do not exist on the MCP server. Path containment is enforced through canonical realpaths, blocking symlink traversal, parent-directory escapes, and absolute-path tricks. Sensitive files—dotenv files, SSH keys, credentials—are denied by default, though dotenv example files are allowed for context. Users can layer additional denials via a c2cignore file.

The OAuth implementation is pedantic in the useful sense: PKCE S256, dynamic client registration, rotating refresh tokens, and revocation endpoints. Knowing the public tunnel URL grants nothing; without a valid token bound to a specific workspace, the server returns 401, and a token valid for the wrong workspace returns 403. The threat model document acknowledges that the browser remains a trust boundary, but it minimizes what that boundary protects. The model never holds credentials that outlive a single planning session.

This design directly addresses the anxiety that accompanies autonomous coding agents. A recent survey of agent architectures notes that execution marks the boundary between assistive and autonomous systems, and that production deployments increasingly isolate reasoning from execution through standardized tool protocols [8]. By making the bridge read-only and the execution loop local, the project keeps the autonomy where the user can see it.

The Shadow of Vibe Architecting

The repository arrives at a moment when researchers are warning about vibe architecting, a term coined in a recent arXiv paper to describe architecture shaped by prompts rather than deliberate design [2]. The authors identify agent-driven architecture as a phenomenon where tools such as Codex, Claude Code, and Cursor autonomously select frameworks, databases, and deployment targets without explicit justification, accumulating technical debt before the system ever runs.

This project does not eliminate that risk—ChatGPT still proposes the plans—but it imposes a governance layer. Because the web-based planner has no write access, it cannot silently lock in an architectural choice by committing a dependency or scaffolding a database. Codex, which holds the execution keys, can reject or modify the plan during implementation. The review loop then forces ChatGPT to inspect the actual git diff and test records through the read-only MCP tools rather than trusting an all-tests-passed summary. It is a poor man’s separation of duties, enforced by file permissions and network topology rather than corporate policy.

The broader industry is converging on similar splits. Deep agent architectures now routinely separate orchestrators, explorers, and coders, feeding each distilled context from a shared store rather than monolithic prompt histories [10]. The plan-code-execute pattern, where an analyst agent grounds a planner and a coder writes standalone scripts, has shown that hallucinations drop sharply when each role is constrained to a narrow interface [5]. This repository applies that insight to the OpenAI product stack using the Model Context Protocol, an open standard recently donated to the Linux Foundation’s Agentic AI Foundation that reduces integration overhead by treating tools, resources, and prompts as scoped, composable units [8].

The Unofficial Status and the Rough Edges

The project is explicit about its limitations. It is unofficial, unaffiliated with OpenAI, and currently at V1. It relies on the ChatGPT web interface—a surface that OpenAI can change without notice—and on Cloudflare’s Quick Tunnel service for public reachability. If either shifts, the bridge breaks.

There is also a certain irony in the installation method. The README offers a one-paste install prompt that users literally feed to Codex, instructing the agent to clone the repository, build the project, copy a Skill file, and run a first-time setup that includes opening a built-in browser to authenticate ChatGPT. The prompt ends with a blunt instruction: the user does not know what MCP, OAuth, tunnels or ports are, does not want them explained, and expects Codex to fix any problems itself. It is a prompt-engineering hack that asks Codex to install its own supervisor, a recursive trust fall that only works because the Skill system itself is sandboxed.

The auto-update mechanism is similarly clever and slightly unnerving: the Skill checks GitHub once a day and updates itself when a new version appears. For a security-sensitive tool that handles OAuth tokens and workspace access, silent auto-updates are a convenience that could become a supply-chain liability. The repository includes seventy-six tests covering path security, OAuth flows, and MCP end-to-end behavior, but test coverage is not a guarantee against future architectural drift.

Why the Quota Math Matters

At its core, the project is a rationing device. ChatGPT Plus and Pro subscribers pay for web access that often sits idle while Codex consumes scarce API tokens on planning and review. By moving the thinking to the subscription already paid for and reserving Codex credits for execution, the project stretches a limited budget. In an ecosystem where agentic coding is becoming the default workflow—OpenAI claims over five million weekly Codex users, with more than one million using it outside software development [9]—this kind of quota arbitrage is a practical necessity.

More importantly, it validates a product gap. Users want a persistent, shared workspace where a planner and an executor coexist without the user acting as a human clipboard [6]. Until OpenAI builds that natively, this read-only bridge is the most rigorous attempt to wire the browser chat and the local agent together without handing the keys to the cloud.

Sources

  1. Codex in ChatGPT | AI Coding Agents for Software ...
  2. How AI Coding Agents Shape Software Architecture - arXiv
  3. Use cases
  4. Using ChatGPT for Planning vs Codex?
  5. Plan–Code–Execute: Designing Agents That Create Their Own Tools
  6. fully integrated local multi-agent coding workflow - ChatGPT
  7. New Codex Update. I don't understand the new “ChatGPT ...
  8. How Do AI Agents Execute Code? | Blaxel Blog
  9. ChatGPT is now a partner for your most ambitious work
  10. A Deep Dive into Deep Agent Architecture for AI Coding Assistants
  11. My best workflow so far for building projects with ChatGPT ...
  12. Full Walkthrough: Workflow for AI Coding — Matt Pocock - YouTube

heatdrop uses Google Analytics to see which pages get read — nothing else. Your call. How we handle data.