CodexPro turns ChatGPT's Developer Mode into a coding agent that touches only one local repo, and it draws a hard line at what that agent is allowed to do. The README spends as much space telling you what the tool refuses to be as it does explaining what it does: "not a hosted service, model proxy, quota bypass, account pool, or OS sandbox." That framing is the most interesting thing here. It reads like a project that expects to be misread, and gets ahead of it.
The actual mechanism
You install the CLI with npm install -g codexpro, run codexpro setup inside a repo, and it starts a local MCP server scoped to that workspace. In ChatGPT, you register the printed Server URL under Settings, Apps, Advanced settings, Create app, with authentication set to None because CodexPro carries its own URL token instead. From then on, codexpro start in the same repo is the daily entry point.
Once connected, ChatGPT gets a fixed set of tools against your working tree: read files, search code, make scoped edits through write, edit, or a guarded apply_patch, run verification commands through a bash tool, and review what changed with show_changes. It can also write handoff plans under a .ai-bridge directory and export a context bundle for model surfaces that cannot call tools at all. This is a defined surface, not open shell access dressed up as an assistant.
Guardrails are the product
The safety defaults are specific enough to suggest the author has thought about how this gets abused. Public tunnel mode requires a token. Generic writes stay hidden unless you set CODEXPRO_WRITE_MODE=workspace. The safe bash layer blocks broad shell patterns and secret, build, and cache paths. apply_patch is workspace-scoped and rejects blocked paths, symlink patches, and patch content that looks like a secret. The handoff feature makes the boundary explicit: handoff_to_agent is planning-only over MCP, and the README states plainly that CodexPro "does not expose arbitrary local agent execution as a remote ChatGPT tool." If you want execution, you run codexpro execute-handoff yourself, locally.
That distinction matters because the whole design exposes a local machine to a web client through a tunnel. The README points you at SECURITY.md before you expose anything through a tunnel, which is the right instinct for a tool whose failure mode is a public HTTPS route into your filesystem.
Connecting the web client to localhost
Because ChatGPT web needs a public HTTPS URL, CodexPro bundles several ways to get one: a Cloudflare quick tunnel for a throwaway demo URL, a stable ngrok domain, a stable named Cloudflare route, a Tailscale Funnel, or local-only with no tunnel. The Tailscale path is the most involved, requiring MagicDNS, HTTPS certificates, and Funnel policy already enabled on your tailnet, after which CodexPro runs tailscale funnel http://127.0.0.1:8787 and ChatGPT reaches it through a URL carrying the stable token. For stable modes the README pushes you to keep that token fixed, which is sensible since the token is what stands between your repo and anyone who finds the URL.
Who this is for
CodexPro is worth a look if you already pay for ChatGPT, want it editing a real repo, and would rather bound that access with an explicit tool list than hand over a general shell. The --mode pro and pro-bundle commands extend the same idea to models that cannot call tools, packaging context for copy-paste instead. The README is thin on how well the agent actually performs on real tasks, so treat the tool inventory as the honest description and reserve judgment on quality until you run it. What it does document, including RAM handling notes about a reusable 64 KiB buffer for binary-file checks and compacted tool-card payloads, is concrete rather than aspirational. For a project this young, the restraint in its own claims is a good sign.
GitHub: https://github.com/rebel0789/codexpro
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Top comments (0)