GitHub Codex-with-ChatGPT: What Happens When ChatGPT Becomes the Brain and Codex Does the Work?

Codex with ChatGPT is an open source project that connects ChatGPT and Codex into a single coding workflow. ChatGPT handles planning, reasoning, and review, while Codex remains responsible for editing files, running commands, testing changes, and doing the actual work inside a project. Instead of asking one coding agent to plan a task, execute it, inspect its own work, and decide whether it succeeded, the project deliberately separates those responsibilities between two OpenAI systems.

The concept is surprisingly easy to understand once the infrastructure is stripped away. You give Codex a task. ChatGPT studies the project and helps develop the plan. Codex performs the work locally. ChatGPT then looks at the resulting changes, test information, and execution records before deciding whether the task is complete or another pass is needed. The project describes the relationship simply: ChatGPT thinks. Codex works.

That idea has attracted considerable attention in a short period. The repository was created on August 28, 2026 and has already accumulated more than 5,500 GitHub stars and hundreds of forks. There is no conventional desktop application or installer here. Codex with ChatGPT is infrastructure for people who already use Codex, ChatGPT, and developer tooling, and its value comes from changing how those systems cooperate rather than giving users another coding interface.

Two AI systems with deliberately different responsibilities

Most coding agents are built around one model that receives a task and repeatedly decides what to do next. The model may inspect files, generate code, run tests, read failures, modify the implementation again, and eventually decide that its own work is complete.

Codex with ChatGPT changes that structure. ChatGPT becomes the planning and review layer while Codex retains execution authority. The project moves through a defined workflow involving initialization, planning, execution, review, and completion. ChatGPT can inspect what actually happened after Codex finishes an iteration instead of relying entirely on Codex reporting that everything worked.

There is a useful idea underneath that separation. A system reviewing its own work can repeat the same assumptions that produced a mistake in the first place. Giving another model access to the resulting code changes and test information creates at least some distance between implementation and review.

That does not guarantee better software. ChatGPT and Codex can misunderstand the same requirement, and adding a second model introduces another source of mistakes. The architecture is still interesting because it stops treating one agent as planner, programmer, tester, reviewer, and final authority simultaneously.

ChatGPT can inspect the project without controlling it

The bridge between ChatGPT and the local workspace uses MCP. ChatGPT receives access to a limited collection of read only tools that let it inspect the project while Codex remains responsible for anything that changes the machine.

Those tools expose information such as workspace structure, file contents, workspace search, Git status, Git diffs, test status, execution summaries, and selected execution output. ChatGPT can therefore investigate what Codex changed without receiving shell access or file modification tools through the bridge.

This is one of the stronger architectural choices in the project. The server does not merely tell ChatGPT not to edit anything. Write, delete, shell, and commit operations are not exposed through the MCP interface in the first place.

The control messages exchanged between the systems are also kept relatively small. Instead of constantly copying whole files, giant diffs, or command logs between the two systems, ChatGPT requests workspace information through the bridge when it needs it. The repository stays local rather than being uploaded as one large package.

The security design is more serious than the project name suggests

Connecting a local programming workspace to a cloud based AI interface creates obvious security problems. A careless bridge could expose environment variables, private keys, credentials, source files, or even execution access to anyone who reached the service.

Codex with ChatGPT has clearly spent significant effort on those boundaries. Workspace paths are resolved against a canonical root before access is allowed. Attempts to escape through parent directories, absolute paths, or symbolic links are checked. Sensitive file rules block common credential and environment file patterns, and users can extend those restrictions with their own ignore rules.

Authentication uses OAuth 2.1 with PKCE, rotating refresh tokens, and a pairing process. The browser sees a temporary pairing code rather than a permanent local credential. Tokens are tied to a specific workspace, and the local bridge itself listens only on the loopback interface.

Recent versions have continued tightening this area. The project has added protections around sensitive files appearing inside Git diffs, files renamed across directory boundaries, OAuth page rendering, malformed execution records, tunnel verification, and structured MCP output. The repository also contains a substantial automated test suite focused on workspace boundaries, authentication, pairing, and MCP behavior.

For a community project that appeared only weeks ago, the security work is considerably more deliberate than the usual experimental bridge between two AI tools.

Cloudflare makes the connection possible

ChatGPT cannot directly reach a service that only exists on a developer's local machine, so Codex with ChatGPT uses Cloudflare tunnels to expose the bridge.

By default, the project can create a temporary public address. That address may change when the bridge restarts, so the system includes repair logic that updates the ChatGPT connector when necessary. Users with a Cloudflare account and their own domain can instead configure a stable hostname.

The local bridge still binds to the local machine rather than listening openly on every interface. Cloudflare becomes the controlled path between ChatGPT and that local service.

This architecture works, but it also shows how much machinery sits behind the simple ChatGPT thinks, Codex works slogan. The full system includes Codex, ChatGPT, MCP, OAuth, a local Node service, Cloudflare, browser automation, persistent state, workspace security rules, and update logic.

The project tries to hide much of that complexity through automation. Codex can install the required dependencies, clone the repository, build the project, install the skill, configure the bridge, and guide the user through connecting ChatGPT.

The user is supposed to become involved only when a step genuinely requires human participation, such as signing in, completing authentication, or responding to a verification challenge.

The installation process is itself agent driven

There is no traditional installer. Instead, the project provides instructions that can be handed directly to Codex.

Codex checks the environment, ensures Git and a sufficiently recent Node installation are available, installs the necessary Cloudflare tooling, clones the repository, installs dependencies, builds the project, places the Codex skill in the correct location, and walks through connector setup.

This is a clever use of a coding agent as its own installer. It also means the project is not aimed at someone casually browsing for a desktop application. The user already needs enough of the OpenAI development ecosystem in place for the workflow to make sense.

The project is written primarily in TypeScript and uses fairly conventional Node components around the command line interface, HTTP service, validation, testing, and MCP integration. It currently requires Node 20 or newer.

Once installation is complete, the complexity becomes less visible. A developer can simply ask Codex to use ChatGPT while performing a task, and the bridge manages much of the communication behind the scenes.

The review loop is where the project becomes genuinely interesting

After ChatGPT produces a plan, Codex executes the work locally. It edits files, runs commands, performs tests, and records the result. ChatGPT can then inspect the actual Git diff and execution information through the bridge before reviewing the implementation.

If ChatGPT finds a problem, Codex can perform another iteration. If the result looks correct, the workflow can finish.

This creates something closer to a programmer and reviewer relationship than a single agent repeatedly talking to itself. The reviewer has access to the actual state of the repository rather than simply receiving a summary generated by the same system that made the changes.

The project also supports local checkpoints so interrupted sessions can resume with information about the current goal, protocol position, and next step. Execution output can be recorded for review, but a local sanitizer attempts to remove sensitive information before making that output available through MCP. Private key material can be blocked entirely, while common secret patterns and local paths are redacted.

The architecture is still young, but the amount of thought going into the review loop is more substantial than the repository name initially suggests.

Code review found a few real weaknesses

The path containment and sensitive file filtering code looked thoughtfully designed during our review. The project does not simply trust model input when resolving local files, and several security boundaries are enforced directly in code rather than through prompts. We still found a handful of areas where the implementation could be tightened.

The clearest bug appears in OAuth scope handling. When a client requests recognized permissions, the bridge filters the request down to the supported set. If the request contains only permissions the bridge does not recognize, however, the current implementation falls back to granting every supported scope.

That is the opposite of the safer behavior. An invalid permission request should be rejected or receive no valid scopes. It should not unexpectedly gain workspace reading, workspace searching, Git access, execution information, and persistent access simply because none of its requested permissions matched.

The code responsible for this behavior is small, but permission handling is exactly the kind of place where a small mistake can have an outsized effect. Of the issues we found, this is the one I would correct first.

There is also a possible denial of service issue in the fallback workspace search engine. When ripgrep is available, the project uses it for searches. When it is not available, the bridge falls back to a JavaScript implementation. If regex search is enabled, an authenticated caller can provide an expression that is passed directly into JavaScript RegExp.

Certain pathological regular expressions can consume enormous amounts of CPU time. Because the fallback engine evaluates the expression repeatedly across workspace files, a sufficiently expensive pattern could temporarily freeze the bridge process. This is not an unauthenticated remote attack because the caller already needs access to the bridge, but placing limits around expression length or evaluation cost would make the fallback more resilient.

A smaller OAuth issue appears during authorization code redemption. The bridge currently removes an authorization code before verifying the client identity, redirect address, and PKCE verifier. Authorization codes are supposed to be usable only once, but consuming the code before those checks means someone who somehow obtains it could intentionally submit an invalid redemption and destroy the legitimate login attempt.

PKCE still prevents the attacker from turning that code into a valid session without the verifier, so this is better understood as a reliability and denial of service weakness than an account takeover path. The cleaner behavior would be to validate the redemption first and consume the code only after the checks succeed.

The largest practical trust concern is not a conventional security bug at all. The installed skill can update the project, install packages, modify configuration, rebuild itself, and replace its own instructions as newer versions arrive. That makes maintenance extremely convenient, but it also means the code a developer reviewed today may not be the exact code running later.

For developers using the bridge with commercially valuable or highly sensitive repositories, a more conservative setup would be to pin a reviewed version and require approval before updates or configuration changes are applied. Automatic updates are useful for a fast moving community project, but they also widen the trust relationship from the version currently installed to whatever the repository may contain tomorrow.

The project also currently declares the MCP software development kit dependency using the word latest rather than an exact package version. The lockfile reduces the immediate risk because normal locked installations will still resolve to the recorded version, but using an exact dependency version in the manifest would make the build more reproducible and reduce surprises during future dependency resolution.

None of these findings erase the stronger parts of the security design. Workspace containment, sensitive file filtering, read only MCP access, OAuth, pairing, and execution separation are all sensible choices. The issues we found are more characteristic of a young security sensitive project accumulating complexity quickly than evidence that the overall architecture was careless.

Two models also mean twice the coordination

Separating planning from execution has benefits, but it inevitably adds complexity. A normal Codex session can inspect a repository and begin working almost immediately. Codex with ChatGPT has to maintain a bridge, connector, authentication state, workspace association, session state, and public tunnel before the collaboration can function.

Every extra service creates another place where something can fail. The tunnel can break. Authentication state can expire. The connector can become stale. The local bridge can stop. ChatGPT can misunderstand the project. Codex can misunderstand the plan. The two systems can disagree.

There is also no guarantee that ChatGPT will consistently produce a better plan than Codex would have produced alone. The value depends heavily on the task.

For a tiny change, the extra machinery may make little sense. Fixing a spelling error or adjusting a simple component probably does not justify a separate planning and review system.

For larger tasks, the idea becomes much more interesting. Refactoring several modules, changing architecture, investigating a difficult bug, or implementing a feature that touches multiple areas of a repository gives the independent planning and review layer more opportunity to catch something meaningful.

This may be closer to the future of coding agents

The broader idea behind Codex with ChatGPT extends beyond these two specific products. AI development tools are gradually moving away from the idea that one increasingly large model should perform every role.

One model can plan. Another can execute. A deterministic system can enforce permissions. A smaller model can classify information. A test runner can verify behavior. Another model can review the resulting changes. That starts to look less like a chatbot writing code and more like a development environment built from specialized intelligent components.

Codex with ChatGPT demonstrates that idea unusually clearly because it intentionally prevents ChatGPT from becoming the execution engine. Codex remains the system allowed to modify the project, while ChatGPT becomes an independent reader and reviewer.

The separation itself is the experiment.

Who is Codex with ChatGPT for?

The project makes the most sense for developers who already use Codex extensively and also have access to ChatGPT. It is particularly interesting for people using coding agents on tasks large enough that planning, review, and repeated debugging consume a significant portion of the session.

It is much less useful for someone looking for a normal consumer application. There is no desktop interface to explore and no immediate benefit unless you already understand why you would want one AI system planning and another executing.

Developers interested in agent architecture may find the repository valuable even if they never adopt it permanently. It provides a fairly concrete example of how MCP, OAuth, browser automation, local execution, security boundaries, and multiple AI systems can be combined into one workflow.

Final assessment

Codex with ChatGPT takes an extremely simple idea and builds a surprising amount of infrastructure around it. ChatGPT plans and reviews. Codex edits and executes. A restricted bridge lets ChatGPT inspect the project without giving it the same authority as the execution system.

The strongest part of the project is that the separation is not merely conceptual. The permission model actually reflects it. ChatGPT receives read oriented workspace tools rather than shell access, while Codex retains responsibility for changing the machine.

The security implementation is also more mature than expected for a project this young. Workspace containment, sensitive file protection, authentication, pairing, structured output, and regression testing have all received meaningful attention. Our review still found real weaknesses, particularly the OAuth scope fallback, but they look fixable rather than fundamental.

The biggest downside is complexity. A system involving ChatGPT, Codex, MCP, OAuth, Cloudflare, browser automation, local services, persistent state, and automatic updates has far more moving parts than a normal coding session. The project works hard to hide that machinery from the user, but the machinery is still there.

More than 5,500 stars in only a few weeks suggests developers are interested in the concept. The larger question is whether the extra planning and review layer improves results consistently enough to justify the infrastructure.

If independent review catches mistakes that a single coding agent would otherwise ship, the project has a compelling argument. If both systems mostly agree and the second loop simply adds latency, the advantage becomes harder to defend.

Either way, Codex with ChatGPT is a useful glimpse at where AI coding systems may be heading. The next generation of development tools may not be one giant model responsible for everything. It may be several specialized systems, each given exactly enough access to perform one part of the job.

Repository found here: https://github.com/XiaoDuoYa/codex-with-chatgpt

Article by Daniel Carr, MSW - Owner of ElseBoard.com