The user should not be the synchronization layer: from ChatGPT and Codex context to Project context
I would like to share a product observation that emerged from using ChatGPT and Codex CLI extensively in real software development.
This is not really a request for a specific feature. I think it may point to a broader product opportunity around how ChatGPT and Codex understand the same project.
How I got here
My use of ChatGPT for software development evolved gradually.
At first, I used ChatGPT to write individual functions.
Then I started asking it to create or rewrite entire files.
The results were extremely useful, but the workflow became increasingly tedious:
Discuss in ChatGPT → generate code → copy it to my Linux server → test it → bring the resulting code back to ChatGPT → discuss changes → copy it again.
The intelligence was there.
The connection to the actual development environment was not.
Then Codex CLI changed that.
Being able to let Codex work where the software actually lives — inspect the repository, understand surrounding code, modify files, run commands, test changes, and iterate — dramatically accelerated my development process.
But after working this way for some time, I increasingly feel there is one more barrier to remove.
ChatGPT knows one part of my project. Codex knows another.
I use ChatGPT and Codex for different but highly complementary purposes.
Codex is close to the implementation. It can understand what is actually in my repositories right now.
ChatGPT is where much of the broader thinking happens.
I use long-running ChatGPT conversations for architecture, product decisions, requirements, documentation strategy, trade-offs, brainstorming, and discussions about what a system should become.
These conversations can develop substantial context over time.
But ChatGPT does not necessarily know what Codex knows about the current implementation.
And Codex does not necessarily know the broader reasoning and history contained in those conversations.
So I, the user, become responsible for keeping those two contexts synchronized.
The user should not be the synchronization layer.
A concrete example
I am currently working on a fairly large software platform distributed across multiple Linux servers and services.
In one of my ChatGPT conversations, I am designing a documentation system for that platform.
The conversation can become quite sophisticated. We can discuss what the documentation system should understand, its architecture, how it should represent the platform, what information matters, and how it should evolve.
Now imagine that, during that same conversation, I could explicitly authorize ChatGPT to use the current development context already available through my Codex environment.
I could ask:
“Given everything we have discussed about the documentation system, look at how this part of the platform actually works today. Does our design still make sense?”
Or:
“We discussed this architecture three weeks ago. A substantial part of it has since been implemented through Codex. Review the current state of the repository and let’s continue the design discussion from there.”
That would be extraordinarily powerful.
ChatGPT would not depend entirely on my description of the implementation.
The conversation could be grounded in the evolving reality of the project.
I can approximate this today — but I probably shouldn’t have to
Technically, I could package my repositories, upload them into a ChatGPT Project, explain which components run on which servers, describe their relationships, and periodically repeat the process as development continues.
But this feels like manually reconstructing information that already exists elsewhere in my OpenAI workflow.
Codex already works with this development context.
What seems to be missing is a user-controlled way of allowing that context to participate in a ChatGPT conversation when relevant.
Not unrestricted access.
Not automatically mixing everything together.
Explicit, permissioned access to shared project context.
Maybe the unit of collaboration should become the Project
The simplest way I can describe the opportunity is this:
ChatGPT understands the conversation.
Codex understands the code.
The next step may be for OpenAI to understand the project.
A project could become the conceptual layer connecting conversations, repositories, implementation history, architecture, documentation, and eventually other relevant sources.
ChatGPT and Codex could remain different experiences optimized for different kinds of work.
They would simply be looking at different aspects of the same underlying project context.
That distinction seems important.
I am not suggesting that ChatGPT should become Codex, or that Codex should become ChatGPT.
Their different interaction models are useful.
What I would like to remove is the need for the human between them to continually explain what the other one knows.
Why I think this could matter
My experience with OpenAI’s development tools has gone through what feels like three stages:
Stage 1 — AI generates code
ChatGPT helped me write functions and files.
Stage 2 — AI works where the code lives
Codex CLI removed an enormous amount of friction by connecting the AI directly to the development environment.
That dramatically changed my workflow.
Stage 3 — AI understands the project
This is the step I now find myself wanting.
Not simply more context, but continuity between the place where implementation happens and the place where broader reasoning happens.
Codex dramatically improved my workflow by connecting AI to where the code lives.
I suspect another similarly important improvement could come from connecting that implementation context to where the thinking lives.
One final note
I intentionally do not want to prescribe how this should be implemented.
There are obvious questions around permissions, security, context boundaries, repositories, environments, memory, synchronization, and UX. OpenAI’s product and engineering teams are much better positioned to explore those questions.
I simply wanted to describe a friction that has become increasingly visible through real, intensive use of both products.
If this observation is useful to the people thinking about the future relationship between ChatGPT and Codex, then sharing it has served its purpose.
Disclosure: This post was written collaboratively with ChatGPT.
The experience, workflow, and product observation described here are mine. I explained the idea to ChatGPT through conversation and asked it to help me structure and articulate it clearly.
I chose to mention this explicitly because it is also a small demonstration of the idea behind this post: ChatGPT already participates deeply in the reasoning around my projects. Codex participates deeply in their implementation.
I would love for those two forms of collaboration to eventually share an understanding of the same project.