CodexPro: an MCP server that gives ChatGPT write access to repos you allow

The gap CodexPro fills between a chat window and your working tree

A ChatGPT session can reason about code you paste into it. It cannot see your repository, run your test command, or write a file back. CodexPro exists to close that specific gap without turning your machine into a remote shell. The README is blunt about the boundary: it is a local MCP server that connects your ChatGPT session to your machine and to repos you explicitly allow, and it stays inside those roots.

The audience is narrow and worth naming. You need Node.js 20 or newer, a ChatGPT account that can create custom MCP plugins, and an HTTPS URL that reaches your machine for ChatGPT web. If any of those three is missing, the tool has nothing to attach to. The README also lists what it is not: not a hosted SaaS product, not a model proxy, not a quota bypass, not an account pool, not a remote shell service. That list reads like an answer to a category of tools that promise ChatGPT access while actually reselling API keys. CodexPro does not do that, and the distinction matters when you are deciding whether to install it on a work laptop.

How the local MCP server, the tunnel and the plugin fit together

Three pieces have to line up. The first is a CodexPro process running on your machine, launched with codexpro start from a repository, or with an explicit --root. The second is an HTTPS endpoint that ChatGPT's servers can reach, produced by a tunnel command or by Tailscale Funnel. The third is a ChatGPT plugin whose Server URL points at that endpoint.

Once connected, ChatGPT talks to the MCP server and the server acts on the allowed roots. According to the README, the tool surface includes reading and searching the repo, editing through write, edit, or a guarded apply_patch, importing ChatGPT attachments with import_file, running allowlisted checks with bash, reviewing diffs with show_changes, and writing plans under .ai-bridge. There is also an export of a context bundle for chats that cannot call tools at all, which is a sensible escape hatch for the case where you want the repo contents in a conversation that has no plugin support.

The isolation model is process-level rather than user-level. One CodexPro process can allow more than one repo, and ChatGPT switches between them with open_workspace, with open_current_workspace returning to the launch repo. The README's answer to two ChatGPT accounts or hard isolation is to run two CodexPro processes on different ports and Server URLs. That is a real constraint: there is no multi-tenant layer inside a single process, so separation means running more than one.

Installing CodexPro and connecting the plugin

Installation is a global npm install followed by a setup command run from inside the repository you want to expose. The README gives this sequence, and the setup step is what copies the connection URL you will paste into ChatGPT.

npm install -g codexpro
cd /path/to/your/repo
codexpro setup

After that, the plugin has to be created in ChatGPT's own settings, and the README is unusually specific about the path because the form has traps. Turn Developer mode on under Settings -> Security and login, keeping CSP enforcement on. Then go to Settings -> Plugins, open the Plugins tab, and click the plus button beside Search plugins. Name the plugin CodexPro, set Connection to Server URL, and paste the URL that codexpro setup copied. For Authentication, choose No Authentication / None, and the README warns that the form may default to OAuth instead. The token is already inside that URL, which is why the README says not to share it.

Daily use is a single command from the same repository.

codexpro start

If plugin creation fails, the README's suggested diagnostic is codexpro connection-test, which checks whether ChatGPT's requests are reaching the local server. That is the first thing to run when the plugin appears connected but no tool call ever arrives.

For a first real use, ask ChatGPT to open_workspace on the allowed project and then to read a file you know the contents of. If the returned text matches, the read path works. Editing is the second test, and it will not do anything until write mode is workspace, because the safety defaults keep writes hidden otherwise.

Public HTTPS options and the token that gates them

ChatGPT web needs an HTTPS URL, and the README offers four ways to get one. The cloudflare option produces a quick demo URL that changes. The ngrok and stable commands both take a --hostname, with stable also taking --tunnel-name, and the tailscale command takes a Tailscale hostname. There is also --tunnel none for local-only operation, which is useful when the client is not ChatGPT web.

Stable hostnames bring a token problem, and the README's answer is to keep the token stable too, in a file under ~/.codexpro.

mkdir -p ~/.codexpro
openssl rand -hex 32 > ~/.codexpro/http-token
chmod 600 ~/.codexpro/http-token

The safety defaults require a CodexPro HTTP token of at least 24 bytes on public tunnels, so this file is not optional decoration. The README prefers an Authorization: Bearer header when the client supports headers and describes the ?codexpro_token= query form as a personal compatibility fallback. That ordering is the right instinct: a token in a query string lands in logs and browser history in places a header does not.

This is also the point where the design stops being convenient. A tunnel that changes on every restart is fine for a demo and useless for a plugin you configured once, which is why the stable path exists and why it costs you a domain and a token file to manage.

Where CodexPro is the wrong tool

The largest limitation is structural: CodexPro is a bridge for an interactive ChatGPT session, not an autonomous agent. If you want something that runs on a schedule in CI, opens pull requests and never needs a human in the loop, this is not that. The README describes a plugin you create by hand in ChatGPT's settings and a local process you start yourself. Every session depends on that process being up and on the tunnel URL staying valid.

Write access is the second boundary. The README states that writes stay hidden unless write mode is workspace, that safe bash is the default, and that blocked paths cover .env, keys, .git, build caches and similar. Those are sensible defaults, but they also mean the out-of-the-box experience is read-heavy and the agent will appear to refuse edits until you change the mode. Loosening the mode is the moment the tunnel stops being a curiosity and starts being a risk, and the README's own instruction is to read SECURITY.md before exposing a tunnel.

The third limitation is the ChatGPT plan requirement. Custom MCP plugin creation is not available on every account tier, and the README does not attempt to work around that. It also does not document rollback. If an edit goes wrong, the README points at show_changes for reviewing diffs, but there is no described undo command, so version control on the exposed root is doing the real safety work. Anyone who treats the agent's edits as recoverable without git is making an assumption the documentation does not support.

How it compares with running an agent in the terminal

The obvious alternative is a terminal coding agent that already has filesystem access, such as the Codex CLI that the project's own naming and prompt files gesture at. The difference in approach is where the model runs and what mediates the file operations. A terminal agent runs on your machine and reads and writes the working tree directly, with no tunnel, no token and no plugin configuration. CodexPro inserts an MCP server and an HTTPS hop between the model and the files, because the model is the one in your ChatGPT web session rather than one running locally.

That trade is real in both directions. CodexPro buys you the ChatGPT interface you already use, including attachment import and the conversation history that lives there. It costs you a tunnel, a token file and a process that must stay running. If your only goal is editing files in a repo, the terminal route has fewer moving parts. If your goal is to keep working inside a ChatGPT conversation while it touches real files, CodexPro is the piece that makes that possible, and the README's framing of it as a bridge rather than a product is accurate.

Maintenance, licensing and what an upgrade costs

The repository is MIT licensed, which permits commercial use and modification, and the package is published publicly on npm under the name codexpro. The package.json declares node >=20 in engines, so the runtime floor is enforced at install time rather than left to documentation. There is no retrieved release history, so the practical signal is the commit activity: the last push to main was on 2026-08-08.

Upgrading is one command, followed by a restart of the running process.

npm install -g codexpro@latest
codexpro --version

The README notes that saved profiles under ~/.codexpro stay in place across updates, which is the detail that decides whether an upgrade is disruptive. If your token file and project settings live there, an update does not force you to reconfigure the plugin in ChatGPT. The version in package.json at the time of writing is 0.30.0, and the zero-major version is worth weighing: the command surface has grown a fair amount (setup, doctor, inspect, review, several tunnel subcommands, and multiple tool modes), and pre-1.0 projects can rename or reshape those between releases. Nothing in the README describes a deprecation policy or a compatibility guarantee for the CLI flags.

Editorial conclusion

Adopt CodexPro if you already pay for a ChatGPT plan that can create custom MCP plugins and you want that session to edit files inside one or two repositories on your own machine, with a token in front of the tunnel. Do not adopt it if you need a hosted service, a headless CI agent, or write access you are unwilling to expose through a public HTTPS URL; the README itself points you at SECURITY.md before you open a tunnel. Before trusting it, verify three things on your own checkout: that codexpro setup writes the roots you expect, that codexpro connection-test shows ChatGPT's requests reaching the local server, and that your blocked-path list still covers .env, keys and .git after you change tool mode.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. rebel0789/codexpro on GitHub