codex-with-chatgpt Says Your Repository Is Never Uploaded. Read That Sentence Again.

The top repo on GitHub's trending board bridges ChatGPT's planning brain to a Codex session over a read-only MCP server. The security work is better than most funded products. One sentence in the README is still doing something it shouldn't.

The README for codex-with-chatgpt makes a promise in four words: "Your repository is never uploaded."

That sentence is true. It is also the sentence that will stop most people reading the rest of the security documentation, which is a shame, because the rest of the security documentation is genuinely good and it says something the four words do not. This project's entire reason to exist is to let ChatGPT read selected file contents and git diffs out of your working directory, on demand, over a public tunnel. Nothing is uploaded in bulk. Plenty is sent.

The repo went up on August 28. Twenty-four hours later it was around 670 stars, 74 forks, and the number one slot on the daily trending board. It is version 0.1.0 with no tagged releases. I want to look at what it actually does, because the engineering underneath is more careful than the star count suggests and the gap between the pitch and the mechanism is where the interesting part lives.

The trade it is making

The pitch is arbitrage, stated plainly: "ChatGPT Plus/Pro web quota sits idle while your coding agent burns scarce API/Codex tokens on planning and review." So move the planning to the subscription you already pay for. "ChatGPT thinks. Codex works."

That is a real problem. Planning and code review chew through Codex quota faster than execution does, and a lot of people have a ChatGPT plan sitting mostly unused next to a Codex budget they keep hitting. The obvious hack is copy-paste between two browser tabs, which everybody has done and everybody hates.

What this project builds instead is two separate channels. A control plane carries tiny state messages between the two agents, capped by an explicit rule in the docs: keep messages under 1 KB, no diffs, no logs, no file bodies. Those messages drive a state machine that runs INIT → PLAN → EXECUTING → EXECUTED → REVIEW, then loops or terminates at DONE, BLOCKED, or ERROR. Then a data plane, and this is the actual design idea, lets ChatGPT go get what it needs itself through eight read-only MCP tools: workspace_info, list_directory, read_file, search_workspace, git_status, git_diff, test_status, and execution_summary.

Read-only is enforced by absence, which is the right way to do it. The security doc says it flatly: write files, delete files, run shell commands, commit, install packages, those tools do not exist on the server. You cannot misconfigure your way into a write. There is nothing to misconfigure.

The security work is real, and I mean that

I read a lot of trending agent repos and most of them ship a bearer token in an environment variable and call it authentication. This one runs a full OAuth 2.1 authorization server locally, on your machine, and makes ChatGPT the client. Discovery metadata per RFC 8414, self-service client registration per RFC 7591, authorization code with PKCE and S256 only, refresh rotation, revocation per RFC 7009. Tokens are opaque and stored as SHA-256 hashes, bound to a workspace ID and client ID, one hour for access and thirty days for refresh.

The pairing code is the only secret a human types, and it is specified rather than hand-waved: eight characters from a 31-character CSPRNG alphabet, about 40 bits, five attempts per session, ten per minute per IP, five-minute TTL, single use. The skill file carries a rule I would like to see in more agent tooling: the pairing code is the only credential you may ever type into a browser, never touch OAuth tokens, cookies, or session storage.

Path containment is done properly too. Canonical realpath checks, rejection of symlinks and ../ and absolute paths, line and byte caps on read_file, byte-offset pagination on git_diff, match caps on search. The sensitive-file denylist is deny-by-default and covers .env*, keys, SSH material, and credentials, with .env.example allowed through and a .c2cignore file for your own rules. The bridge binds 127.0.0.1 and refuses 0.0.0.0.

The maintainers also state the prompt-injection problem out loud, which almost nobody does: READMEs, comments, and diffs may contain injected instructions, every MCP tool description carries a warning about it, and tools never grant capabilities based on file content. That is the correct threat model for a tool whose job is feeding repository text to a model.

So where does the code actually go

Here is the part the four-word promise obscures.

The MCP server runs on your machine, on loopback. ChatGPT runs on OpenAI's servers. Something has to connect them, and what connects them is a Cloudflare Quick Tunnel, spawned as a child process, whose public URL gets parsed out of the tunnel's own logs and handed to ChatGPT. When ChatGPT calls read_file or git_diff, the contents of that file and that diff travel out through the public tunnel and land in a ChatGPT conversation.

That is not a flaw. It is the design working as intended, and OAuth is what keeps a stranger who guesses your tunnel URL from doing the same. But "your repository is never uploaded" describes the absence of a bulk transfer, and a reader scanning for reassurance will take it as "my code stays local." Your code does not stay local. Selected parts of it go to OpenAI, into a consumer chat session, under whatever retention applies to consumer chat sessions. The repo has no SECURITY.md, no privacy policy, and no .github directory at all, so there is no statement anywhere about what happens to it on the other side.

There is a second thing worth knowing before you install it. OpenAI's own help documentation says ChatGPT does not connect to local MCP servers directly, and points users to a Secure MCP Tunnel specifically so a developer machine can be reached "without exposing the server to the public internet." This project takes the other road: expose a public Cloudflare URL and defend it with OAuth. Defensible engineering, and it is not the sanctioned path.

And the docs have already drifted from the code. The README and the architecture doc both describe the control plane as "Computer Use." The shipped skill/SKILL.md, which is the file that actually runs, says the opposite in capitals: never Computer Use, no screenshot-click, always the in-app browser. The real mechanism is browser automation driving chatgpt.com through the DOM, polling every twenty to thirty seconds for a state marker. Anyone repeating the README's framing is repeating a label the codebase contradicts. Four commits landed on the day I checked. Treat every number in this article as perishable.

Put this into practice

If you want to try it, the friction is low and the install is more invasive than it looks. Do these in order.

Read docs/security.md before the README. It is the honest document in the repo and it takes five minutes. If anything in it bothers you, you have saved yourself the install.
Write your .c2cignore before you pair, not after. There is an examples/c2cignore.example in the repo. The built-in denylist catches credentials; it does not know which directories in your project you consider none of a chat session's business.
Install the skill and let it drive. Copy skill/ to ~/.codex/skills/codex-with-chatgpt/, then tell Codex "Set up Codex with ChatGPT." You need Node 20 or newer, git, and cloudflared, which the skill installs for you through brew or winget. One gotcha: the shipped skill file hardcodes the maintainer's own machine path for the checkout location, and you have to hand-edit it.
Diff ~/.codex/config.toml before and after c2c sandbox-allow. That command edits your Codex sandbox policy to add the tool's state directory to writable_roots. It is a small, reasonable change and it is a change to the sandbox you rely on for everything else. Look at it.
Run c2c doctor and confirm the bind address. The tool refuses 0.0.0.0 by design; verifying that yourself takes one command and tells you the safety property you are relying on is actually on.
Point it at a scratch repo first. Not client work, not anything under NDA. Watch what read_file and git_diff actually pull across in a session before you decide what it is allowed near.

Expect to re-pair. Quick Tunnel URLs change on every start, so quitting Codex or closing the terminal kills the public address, and reconnection is routine rather than an edge case.

Honest limitations

The repo is a day old and versioned 0.1.0 with zero releases, no CI workflows, and no automated checks visible in the tree. The README claims 76 tests; the tree has eleven test files, and I could not confirm the case count without running the suite, so I would not repeat that number. Token hashes and client registrations live in files rather than the OS keychain, which the maintainers flag themselves as a V1 limitation with keychain integration deferred to V2. Most commits are unsigned.

The install path also asks you to trust it more than a security-conscious tool should. The headline flow is a roughly 250-word prompt you paste into Codex, which then installs system packages, clones a repo, builds it, edits your Codex config, and drives a browser into your ChatGPT settings. The README instructs the agent to hide the mechanism from the user with a line I keep rereading: I don't know what MCP, OAuth, tunnels or ports are, don't explain them. For a tool whose safety depends on the user understanding where their code goes, that is the wrong default, however good the intent.

And there is a terms question I am not going to resolve for you. OpenAI's Terms of Use, effective January 1 2026, list among things you cannot do: automatically or programmatically extract data or Output, and circumvent any rate limits or restrictions. This project's mechanism is an automated agent typing into chatgpt.com and reading replies out of the DOM, and its stated purpose is routing work onto consumer-plan quota instead of metered quota. OpenAI has said nothing about this specific project, there is no enforcement action, and the maintainers post a clear disclaimer that it is unofficial and unaffiliated. Those are the facts. Draw your own line.

What I would watch

The bridge pattern here is going to outlive this particular repo. Somebody has now demonstrated that you can put a local, read-only, OAuth-protected MCP server in front of a consumer chat session and get a real two-agent workflow out of it, and the security scaffolding is good enough to copy. What happens next depends on whether OpenAI treats that as clever integration or as quota arbitrage, and the answer to that is worth more than any feature on the roadmap.

The narrower thing I keep coming back to: this repo does the hard security work well and then writes a sentence that discourages you from checking it. If you build agent tooling, that is the failure mode to steal from, backwards. Say exactly where the data goes. The people who read that sentence carefully are the ones you want using your tool.

If you have run this against a repo that matters, I want to know what git_diff actually pulled across.

Sources: codex-with-chatgpt README; the project's docs/security.md, docs/architecture.md, docs/protocol.md, and skill/SKILL.md; OpenAI Terms of Use; ChatGPT developer mode; OpenAI Help Center on developer mode and MCP apps.