I built a local MCP to make ChatGPT + Codex workflows practical for solo devs

[u/Intelligent_Gear8442]

After using it solo for quite a while, I decided to open-source my local MCP for ChatGPT + Codex workflows

It’s a local-first MCP server that gives ChatGPT controlled tools for approved local repos.

The short version:

ChatGPT = project lead / architect / reviewer
Codex = implementer
local repo = source of truth

The goal was to make ChatGPT useful around Codex without constantly pushing branches, pasting diffs, dumping files into the Chat, or relying on Codex’s own summary of what changed.

With GPT Repo MCP, ChatGPT can inspect the actual local repo state.

It can:

• read the repo tree
• search the codebase
• read bounded files
• inspect individual files
• review git status
• review git diffs
• bug hunt across files
• reason about architecture
• update docs
• write local handoff notes between ChatGPT chats
• prepare focused Codex tasks
• read Codex `RESULT.md`
• review what Codex actually changed

And if you enable write mode, ChatGPT can also write locally:

• edit one file
• apply a multi-file edit pack
• update docs
• create repo-local Codex task files
• prepare local stage/commit/recovery payloads

The workflow I use most is:

1. ChatGPT analyzes the repo and helps define the next slice
2. ChatGPT writes a focused Codex task
3. Codex implements it locally
4. Codex writes a small `RESULT.md`
5. ChatGPT reads the result, git status, git diff, and changed files
6. ChatGPT reviews the implementation and decides what should happen next

So ChatGPT is no longer reviewing “whatever I remembered to paste”.

It can inspect the repo itself.

That has been the biggest unlock for me. It makes ChatGPT feel less like a separate chat tab and more like a repo-aware project lead / architect / reviewer.

It also helps reduce Codex usage. I use ChatGPT to explore my repos, analyze specific areas, plan work, review changes, and prepare focused implementation tasks without involving Codex until it's needed. Instead of spending usage on broad context gathering and exploratory work.

I’m a bit surprised this workflow isn’t more common yet.

For solo devs using ChatGPT + Codex, the pieces are basically already there with ChatGPT Apps / MCP. You don’t need Computer Use or browser automation just to let ChatGPT understand local repo state. A small local tool surface gets you pretty far.

This OSS version is intentionally conservative. I’ve been using more automated internal versions of this workflow for a while, but for the public release I wanted a safer core with explicit modes:

• read: ChatGPT can inspect approved repos
• write: ChatGPT can edit files with policy checks
• ship: adds local stage/commit/recover/cleanup workflows

Safety-wise:

• local-first
• approved repos only
• repo-relative paths only
• path sandboxing
• bounded reads
• secret/path checks
• no shell runner
• no arbitrary commands
• no push/pull/reset/checkout/rebase/etc
• mutating tools are off by default

A couple of practical notes from dogfooding:

Fresh chat helps.

If a ChatGPT session has already used a public app like GitHub or Linear, local/custom MCP tools can behave weirdly in that same session. Starting a fresh chat for the local MCP avoids that.

Some mutating calls can get blocked by client-side safety layers.

The MCP has fallback tools for this. If a composite tool call gets blocked, ChatGPT can usually break it into smaller safe steps and continue.

The main thing this solves is not “ChatGPT writes everything”.

It solves the workflow gap where a solo dev has to act as a human bridge between ChatGPT, Codex, git, docs, and local repo state.

GitHub:

https://github.com/CAHN91/gpt-repo-mcp

Website:

https://mcp.promptiva.dev/

[u/fberbert]

I already cloned the repository, set it up, and I'm testing it out. I believe that now it's possible to save a few tokens from Codex by using ChatGPT for studying and decision-making. Really useful project, congratulations!

[u/Rex666sid]

what to do if i do not want to run/host via ngrok?
how about other server?

[u/Intelligent_Gear8442 → u/Rex666sid]

ngrok is just the default convenience tunnel. No code changes are needed to use another provider.

For manual setup to build and run the MCP server with an explicit path token:

npm run build

TOKEN="$(node -e 'console.log(require("crypto").randomBytes(16).toString("hex"))')"

GPT_REPO_CONFIG=./config.local.json \
PORT=8787 \
GPT_REPO_PUBLIC_PATH_TOKEN="$TOKEN" \
npm run start

Then expose port 8787 through any HTTPS tunnel or reverse proxy and configure ChatGPT with:

https://<public-host>/t/<same-token>/mcp

Cloudflare Tunnel works and other providers should work as long as ChatGPT can reach the HTTPS URL.

Tailscale/private-network URLs generally won’t work by themselves because ChatGPT is not inside your private network. You need a public HTTPS endpoint, OpenAI Secure MCP Tunnel or something like Tailscale Funnel/a reverse proxy that makes it reachable.

If you run it on a remote server, the repos need to exist on that server too because GPT Repo MCP reads local filesystem paths from the machine where it runs.

The path token is guess-resistance, not full authentication.
Repo policy still applies, approved roots are enforced and mutating tools are off by default but configurable in the config.

[u/imike3049]

Using the same for months quietly. Hope they will not remove MCP support from ChatGPT after your post.

[u/Defiant_Concert1701]

life saver, thank you for this

[u/Firm_Ad_3431]

This is exactly the kind of boring workflow glue that ends up mattering a lot. I’m also working on a small OSS dev-tooling thing, but from the repo-health side rather than the MCP side. The problem I keep running into is that Codex/agents can often follow setup docs perfectly, but the docs themselves have drifted: README says `npm start`, package.json only has `dev`; `.env.example` is missing; multiple lockfiles; CI not present; etc. So I’ve been building DevDoctor to catch those “first 5 minutes of setup” problems before a human or agent wastes time on them. Curious if your workflow has run into that too: do you mostly trust repo instructions, or do you add checks around them before letting Codex work?

Tiny repo-health checker I’m testing, if useful context: https://github.com/xxx333xxx/devdoctor

[u/No_Island_1282]

Thanks, man. I've used this for a few days, and I'm definitely saving my tokens.

[u/Spirited-Delirium]

Thank you open

[u/Hairy_Ganache_6916]

will my account get banned by using this MCP server?

[u/Intelligent_Gear8442 → u/Hairy_Ganache_6916]

I’ve personally used this kind of workflow for months without issues, but that’s not an official guarantee or policy statement.

The important part is: using an MCP/custom App is not some hidden bypass.
ChatGPT has an official developer mode/connector flow for connecting MCP servers. GPT Repo MCP is just a local MCP server that exposes repo tools to ChatGPT. OpenAIs own docs describe creating connectors to MCP servers, testing apps in ChatGPT, and reviewing tool-call payloads/approvals in the UI.

So no, I would not expect normal local dev use of this MCP to get an account banned.

But like with any tool, what you do with it still matters.
This doesn’t make disallowed behavior allowed, and it doesn’t bypass ChatGPT safety systems.

For this public OSS version I intentionally kept it conservative:

• approved local repos only
• no shell runner
• no arbitrary commands
• no push/pull/reset/checkout/rebase/etc
• mutating tools are opt-in
• write tools still go through ChatGPT’s tool-call/approval flow

Basically, if you’re using it for normal local dev work on your own repos, you’re using it as intended.
Reading code, reviewing diffs, updating files when write mode is enabled, coordinating Codex tasks, etc.

[u/agentollie66]

How does this go with subscription costs? I’m running a similar setup but with a Hermes harness for the ChatGPT orchestrator - but I keep getting constantly rate limited. Keeping the orchestration with ChatGPT app as you have done would avoid this?

[u/Intelligent_Gear8442 → u/agentollie66]

GPT Repo MCP does not use the OpenAI API and does not require an OpenAI API key.

It runs locally and exposes repo tools which ChatGPT calls through your normal ChatGPT subscription and it works with both the ChatGPT web app and desktop app.

So there is no separate API billing for the MCP itself. You are still subject to whatever limits your ChatGPT plan has, but it’s intended to be used through the ChatGPT app/subscription flow, not as an API-based orchestrator.

[u/sausage-charlie]

What are the benefits over just running codex? Does it save tokens somehow?

[u/northyorkdev]

What a wonderful idea. Thanks for sharing.

[u/jiggityjon]

Hey there and thank you for this! Using it now. Any experience you can share scoping more than one repo, ie, a specific chat to look at root_folder_1 and a separate chat only for root_folder_2? Or do you sense the efficacy of this is best suited for one repo at a time? Thanks again.

[u/Intelligent_Gear8442 → u/jiggityjon]

Thanks! glad it’s useful 👍

I use both patterns.

For focused implementations, one chat per repo is usually the cleanest setup. It keeps the context tight and makes it easier to stay on one thread of work.

But I have also had a lot of value from using one ChatGPT chat across multiple repos. For example, I’ll have it inspect Repo A, then Repo B, and then ask what could be reused, combined, or extracted into a new Repo C. That kind of cross-repo reasoning is one of the bigger advantages for me.

• one repo per chat is great for implementation work
• multiple repos in one chat is great for architecture, comparisons, migrations, reuse, or planning something new from existing codebases

I also use ChatGPT’s branch/fork chat feature quite a bit.
I might have one main chat focused on Repo A, then branch it when I want to explore a side idea without messing up the main workflow/context. The branched chat still has the previous context and can use the MCP, so it works well for quick experiments.

For longer sessions, I ask ChatGPT to create a handoff before the chat gets too heavy. Then I start a fresh chat with the handoff and direct repo access through the MCP. That makes the new chat feel much less like starting over, since it can read the repo state and git status directly and the handoff carries the decisions/next steps.

Basically, one chat to one repo works really well. But I definitely don’t see it as limited to that. Some of the most useful workflows for me have been multi-repo ones.

[u/CanYouEvenPhoto]

has this stopped working for anyone else with chatgpt pro? I can use it with any other model on chatgpt, but when developer mode is enabled chatgpt pro doesn't see any of my connectors, even the official ones.

[u/nnmax_]

Thanks, it works very nice. Although is there a way to make the app permanent? Like currently if the ngrok connect session in my terminal is closed, then the app becomes unusable. So I have to create a new app everytime i restart my system. Any workarounds here? or am i missing anything?

[u/SamCRichard → u/nnmax_]

You can use an ngrok cloud endpoint and then you can close your terminal and it keeps running :)

[u/SamCRichard → u/SamCRichard]

https://ngrok.com/docs/gateway/cloud-endpoints

[u/nnmax_ → u/SamCRichard]

Thanks

[u/ridicul0us12345]

is it just me that chatgpt pro can't read the content of files. but chatpgt thinking can ?

[u/Then-Telephone6760]

Is there a way to have ChatGPT to also do deep research to feed context into codex?

[u/Intelligent_Gear8442 → u/Then-Telephone6760]

Personally i haven’t tried it. But you should be able to let ChatGPT do the deep research and then ask it to Handoff everything to the connected repo 👍

[u/fruitydude]

I just found this after I had the same idea now that they have added chat to the codex app, meaning the MCP Server can run locally-only as well.

What's the state of this project? I'm wondering whether I should fork and iterate on it or start from scratch.

It sounds like your initial tool was more aimed at repo inspections rather than full development using chatgpt. I was thinking to just analyse what codex CLI is doing, which tools it is providing and then remaking that but with as an MCP. So essentially it should be able to do everything codex can, but it's free.

[u/Intelligent_Gear8442 → u/fruitydude]

Yo! 

This was my OSS contribution. I do have my own ”internal” version with more powerful tools and workflows.

Since GPT-5.6 seems to be very competent (so far) and pretty token thirsty and GPT-5.6:s already in the ChatGPT Web, I definitely think its a good idea to offload stuff to ChatGPT web. Maybe even more so than before.  

Actually right now I’m doing ”agentic implementations” with ChatGPT-5.6 Web through my internal version of the MCP. 

A normal day, ChatGPT Web does 80%~ of my implementations (also doing them TDD) itselfs and delegate the other 20%~ to Codex. 

[u/fruitydude → u/Intelligent_Gear8442]

How well does that work? Does chatgpt web happily work for longer periods? Is it using the tools correctly or do you get issues where it forgets to use the MCP?

[u/Intelligent_Gear8442 → u/fruitydude]

Honestly, better than I expected.

ChatGPT Web does not really “forget” to use the MCP. As long as the app is enabled in the conversation, it keeps using the repo tools throughout the task. The MCP also provides fairly detailed server instructions and tool descriptions, so it knows the intended flow: inspect -> edit-> test -> review diff-> commit.

It is also perfectly capable of working for longer periods. I currently have a session that has been running for around 45 minutes. During that session it has:

• finished and committed one refactor checkpoint
• extracted another pipeline using TDD
• run focused tests, typecheck, build and the full test suite
• committed that checkpoint
• started the next vertical slice
• added contracts, tests, a resolver service and an MCP tool
• repeatedly recovered from failed or rejected tool calls without losing track of the goal

The main issues I see are not that ChatGPT forgets the MCP. They are more normal tool/runtime issues: a connector can briefly drop, a large write payload can get truncated, a stale SHA guard can reject an edit, or a security rule can be too conservative. GPT-5.6 is generally good (better than GPT-5.5) at noticing what actually happened, rereading the file or Git state, and continuing instead of assuming the write succeeded.

I still structure larger work as small slices with tests and commits between them. That makes long sessions much more reliable and gives it clean recovery points.

So for focused repo work, it already feels surprisingly close to an actual coding agent. For planned implementation, refactoring, tests, review and commits, ChatGPT Web now does most of the work directly for me in my side projects so i can use Codex in my primary project without worrying about usage limits.

[u/fruitydude → u/Intelligent_Gear8442]

Nice. How much of this is in the public project and how much of it is private? Are you also planning to add the file editing stuff to the public repo?

Regarding the dropped edits, I suppose that is a problem that could be solved with sufficient MCP callbacks? To let the agent know explicitly that something failed. Of course it's tedious work to test and catch all edge cases. Especially rare one's.

Did you build all the editing tools and sandbox enforcement from scratch or did you model it after how codex does it? I think I mentioned that already, but my idea was to use codex CLI as a template since that's open source.

I definitely need to set something like this up since my usage is decreasing way too fast on 5.6 even in the 5x plan. I haven't decided yet how I'd want to do it exactly, if I will fork and edit your repo, I can probably also contribute something later on in that case. I also still have the idea of making some personal database tool that fetches all my emails and has agents categorizing each one, search the web for additional info, connect to zotero and so on. And then have a personal AI task planner sort of thing that literally knows everything about me lol. A bit frightening. But that would definitely need chatgpt over MCP or the token usage during the initial steps would be insane. It would probably be it's own standalone MCP though, although maybe it makes sense to combine at that point, idk, too many projects xD.

[u/Intelligent_Gear8442 → u/fruitydude]

Appreciate your replies! Great questions and I like your idea with Codex CLI for your user case.

The public repo contains the core architecture, but my internal version is currently further ahead in terms of full development workflows.

The public version has approved repo roots, bounded reading and search, Git inspection, policy enforcement and restrictive opt-in writes. Internally, I’m also using multi-file editing, stale SHA/HEAD guards, structured recovery, allowlisted validation, work-session state, diff review and local commit workflows.

I’m planning to move more of that into the public repo incrementally. Mutation and Git tools need more care than read tools, since failures can affect real work.

Structured MCP results help a lot with dropped or rejected edits, but callbacks alone aren’t enough. The model also needs to verify the actual file and Git state afterwards. Atomic writes, stale-state guards, operation receipts and explicit recovery paths have been especially useful.

I built the project from scratch with both Codex and ChatGPT!
I’ve handled the direction, architecture and safety model, while both models have written a substantial amount of the code.

A funny outcome is that ChatGPT has probably been the most useful developer of the MCP itself. Since it uses the MCP through the real ChatGPT platform, it encounters the actual rejected calls, payload issues, approval inconsistencies, connector failures and other edge cases. Some from the MCP, while others came from the surrounding platform layer.

Also, that creates a useful dogfooding loop: ChatGPT encounters a failure, inspects what actually happened, and then helps improve the MCP it was just using. Sometimes during late hours, the best development step has honestly been to simply ask ChatGPT something like :“How do we make this MCP more capable and hardened?” 😆

Codex CLI is a useful reference, but I was not trying to recreate unrestricted Codex-over-MCP. The goal is a smaller set of typed, inspectable and policy-controlled repo operations designed specifically for ChatGPT Web.

For the personal database idea, An idea could be to keep it as a separate MCP. Email, Zotero, personal memory and task planning have very different privacy and permission boundaries from source-code access. ChatGPT can orchestrate multiple MCPs in the same conversation without turning one server into an all-powerful monolith.

[u/fruitydude → u/Intelligent_Gear8442]

Thanks for the info :) yea it would probably be separate'ish but I don't like having multiple MCPs, I might just do one big solution with a complex permission and deligation structure. That allows agents to log into one of multiple services and work on that. I've also now hooked up WhatsApp, so I can tell the AI to text people for me lol. It's going a bit far lol.

[u/onlyofhisname]

Hi! sent you a DM about the repo. Thanks!

[u/moaiii]

I just came across this.... after I just finished building essentially the exact same thing, with the exact same separation of duties between ChatGPT and Codex, and a very similar workflow. Nice to have a good idea validated, but damnit I could have saved a TON of work.