CodexPro: An MCP Server That Points ChatGPT At Your Working Tree

The gap CodexPro fills: ChatGPT has no filesystem

A ChatGPT plugin can call tools, but it has no view of the files on your laptop. The usual workaround is to paste code into the chat window, which loses directory structure, truncates long files, and gives the model no way to run a build or a test. CodexPro closes that gap by running a Model Context Protocol server on your machine and registering it as a ChatGPT plugin. The README states the intent plainly: give ChatGPT local coding tools for repos you explicitly allow. The word explicitly matters. Roots are configured, not discovered.

The audience is narrow and identifiable. You need a ChatGPT account that can create custom MCP plugins, which the install section lists as a prerequisite. You need Node.js 20 or newer. You need an HTTPS URL that reaches your machine, because ChatGPT web will not talk to a plaintext localhost listener. If any of those three is missing, the project cannot help you. The README also draws a boundary around 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 a response to how similar tools get misused, and it is worth taking at face value when you decide whether it fits.

What actually happens between the plugin and your files

The process you launch owns a set of allowed roots. When ChatGPT connects, it sees tools rather than a shell prompt. The README enumerates them for workspace write mode: read, search and inspect the repo; edit with write, edit, or a guarded apply_patch; import ChatGPT attachments with import_file; run allowlisted checks with bash; review diffs with show_changes; write plans under .ai-bridge; and export a context bundle for chats that cannot call tools at all. Each of those is a discrete call, so the model has to choose an operation rather than emit arbitrary commands.

Multi-project support is the part that shapes day-to-day behaviour. One CodexPro process can allow more than one repo, set through codexpro settings set --project with repeated flags. The model then calls open_workspace to switch between allowed projects, and open_current_workspace returns to the repo the process was launched from. That is a session-level switch, not a per-call path argument. For two ChatGPT accounts, or for hard isolation between clients, the README says to run two CodexPro processes on different ports and different Server URLs. There is no internal tenancy model, so isolation is achieved by process count.

The bash tool is described as allowlisted and safe by default. The README does not publish the contents of that allowlist in the material available here, so treat the boundary as something to verify in the repository rather than assume. The same applies to the guarded apply_patch: guarded against what, exactly, is not spelled out in the README text.

Setup, tokens and the tunnel decision

Installation is a global npm install followed by a per-repo setup step. The README gives this example: npm install -g codexpro, then cd into your repo, then codexpro setup. After that, daily use is codexpro start from the same directory. On the ChatGPT side, the sequence is Settings, then Security and login, where Developer mode is turned on with CSP enforcement kept on; then Settings, then Plugins, then the plus button beside Search plugins; then a plugin named CodexPro whose connection type is Server URL, with authentication set to No Authentication or None. That last step is the one people get wrong, because the form may default to OAuth. CodexPro's auth is the token embedded in the URL, and the README says not to share that URL.

Tunnels are where the operational cost lives. The README lists codexpro start --tunnel cloudflare for a quick demo URL that changes, codexpro ngrok --hostname your.ngrok-free.dev, codexpro stable --hostname codexpro.example.com --tunnel-name codexpro, and codexpro tailscale --hostname your-device.your-tailnet.ts.net. There is also codexpro start --tunnel none for local-only work. For stable hostnames the README recommends keeping a fixed token: create ~/.codexpro, write 32 random bytes from openssl rand -hex 32 into ~/.codexpro/http-token, and chmod 600 it. Prefer the Authorization: Bearer header where the client supports headers; the ?codexpro_token= query form is described as a personal compatibility fallback. Public tunnels require a CodexPro HTTP token of at least 24 bytes.

Modes, tool cards and the knobs that change blast radius

CodexPro ships several run modes that trade capability for exposure. codexpro start --no-bash removes the shell tool. codexpro start --tool-mode minimal and --tool-mode full adjust how much of the tool surface is advertised. codexpro start --mode handoff and codexpro start --mode pro are named modes whose exact tool sets the README does not enumerate. codexpro start --headless runs without the interactive surface. Separately, opt-in tool cards are enabled by setting CODEXPRO_TOOL_CARDS=1 in the environment before codexpro start. The README does not describe what a tool card renders or how it changes the plugin experience, so if you enable that variable, expect to inspect the behaviour yourself.

The honest reading of this section is that the README names more knobs than it explains. That is a documentation gap, not a design flaw, but it means the defaults carry more weight than usual. The safety defaults listed are: public tunnels require the HTTP token, writes stay hidden unless write mode is workspace, safe bash is the default, blocked paths cover .env, keys, .git, build caches and similar, and attachment import only accepts ChatGPT Apps SDK file objects from approved HTTPS hosts. Those defaults are the actual product boundary. The flags exist to widen it.

Where CodexPro is the wrong tool

The clearest failure mode is the tunnel. ChatGPT web needs HTTPS, and the quickest path, codexpro start --tunnel cloudflare, produces a URL that the README itself says changes. Because CodexPro's authentication is the token inside that URL, a rotating hostname means a rotating credential, which means re-creating or re-editing the plugin. If you cannot get a stable hostname through ngrok, the stable tunnel command, or Tailscale Funnel, the daily workflow degrades into plugin maintenance.

Second, there is no sandbox described here. The bash tool is allowlisted and safe by default, but the model is still executing commands on your machine, and the README's blocked-path list is a denylist covering .env, keys, .git and build caches. Denylists are only as good as their coverage, and the README does not publish the full list in the material available. If your threat model requires that the model cannot reach a file even by indirect means, this is not the layer that enforces it.

Third, this is single-user software. There is no mention of shared sessions, audit logs, or per-user credentials. Two accounts means two processes on two ports, per the README. A team that wants one gateway with role separation should look elsewhere, because CodexPro has no tenancy concept to configure. Fourth, the dependency on ChatGPT's plugin form means you are exposed to that UI changing; the README already warns that the authentication field may default to OAuth, which suggests the form has moved before.

Compared with running an agent in your terminal

The obvious alternative is a terminal-based coding agent that reads and writes the repo directly, with no tunnel and no plugin registration. The difference in approach is where the conversation lives. A terminal agent keeps the model and the filesystem in one process on one machine, so there is nothing to expose and no URL to rotate. CodexPro inverts that: the model stays in ChatGPT, and your repository is published to it through an MCP endpoint.

That inversion buys you the ChatGPT interface, its attachment handling through import_file, and the ability to work from a browser or a phone against a machine you left running. It costs you a public HTTPS surface, a token to manage, and a plugin that must be pointed at the right hostname. If you already have a comfortable terminal agent workflow, CodexPro's value is mostly the chat surface and the attachment import, not the editing itself. The README's own framing supports that reading: the export-a-context-bundle tool exists precisely for chats that cannot call tools, which implies the tool-calling path is the preferred one, not the only one.

Maintenance, updates and the MIT licence

Updating is a global npm install of the latest version followed by codexpro --version to confirm, and the README notes that saved profiles under ~/.codexpro stay in place. You must restart codexpro start after updating, because the running process holds the old code. There is no release history in the material provided, so there is no way to judge cadence from here. The repository is not archived, and the last push recorded is 2026-08-08.

For contributors, the README lists npm install, npm run build, npm run smoke, npm run stress and npm run release:check, with publishing done from the CodexPro root via npm run release:publish. The presence of smoke and stress scripts suggests the project tests itself, though the README does not describe what either covers.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement with no copyleft obligation. It says nothing about the security posture of the code, and it does not transfer any liability to the author. If you are evaluating CodexPro for a workplace, the licence question is easy; the questions that need answers are the tunnel policy, the token storage location, and whether the blocked-path list matches your organisation's definition of sensitive files. The README directs readers to SECURITY.md before exposing a tunnel, and that is the document to read first.

Editorial conclusion

Adopt CodexPro if you already pay for ChatGPT, want tool calls to hit files on your own disk, and are willing to run a tunnel plus a bearer token to get there. Do not adopt it if you need a hosted service, a shared team gateway, or a sandbox around the model's shell access, because there is none here. Before exposing anything, run codexpro doctor and codexpro connection-test locally, read SECURITY.md, and confirm that the tunnel you pick gives you a hostname stable enough to paste into the ChatGPT plugin form more than once. If your only HTTPS option is a quick Cloudflare demo URL, the token in that URL rotates with the hostname.

Official sources

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