Codex Co² Turns One AI Pair-Programming Session into a Team Workspace
The "Chair" We Moved Back
In the past, two programmers who wanted to solve the same problem together could move their chairs over to the same screen.
One person operated the keyboard while the other reviewed the approach. When a disagreement came up, they'd stop and discuss it. The code on the screen was the joint output of the two, and the full context of the problem gradually aligned through that question-and-answer exchange.
This way of working together is called "pair programming."
Now, AI has become the new partner sitting on the other side of our screen.
We describe requirements to it, ask it to read code, analyze problems, and attempt changes. After many rounds of conversation, that session gradually accumulates the full context of the task, including why the feature is being built, which approaches were rejected, and what constraints must be respected.
But when a colleague wants to join in or take over the work, things start to become inefficient.
We have to screenshot the conversation, copy the code, and then relay the colleague's comments back to the AI. If the other person wants to ask a follow-up question, we have to wait until we feed the question in and then carry the answer back.
AI is already capable of participating in more and more execution work, yet collaboration between people can still be held back by these back-and-forth relays.
Individual productivity is amplified, but the information held by the team doesn't necessarily flow together as smoothly.
It's time to move that "chair" back.
What Does Codex Co² Aim to Solve?
Collaboration on the same session is exactly the problem I want to solve with Codex Co².
The full name of Codex Co² is Codex Conversation Collaboration. The name is a bit long, but what it tries to do is simple: let multiple people participate in the same Codex session and move the work forward together.
The sharer can continue working in the official Codex Desktop. In Co², they simply select an existing session, generate an invite, and send it to collaborators. The collaborator opens the invite in a browser and requests to join. Once approved, they can read the shared context, add requirements to the same agent, and track its responses.
Collaborators don't need to install Co² or separately log in to Codex. Every message they send reuses the sharer's current session tools, permissions, and quota.
Inviting a Collaborator
Let's look at a concrete example.
Suppose a user reports: "The task was marked as completed, but the page status didn't change until I refreshed."
After getting the FeedbackID, the operations person can first analyze the relevant user logs in Codex and reach a preliminary conclusion: the operation request succeeded; the problem might be in the page status update step.
Then, the operations person can share this session with engineering through Co².
After joining, the engineer can continue from the existing analysis: Did the server send a status change notification? Did the client receive it? Before the anomaly, did a disconnect and reconnect happen?
Combining logs and related code, the problem gradually narrows down: the client didn't resume its real-time subscription after network reconnection, so subsequent status changes didn't reach the page; manual refresh re-fetches data, so the display returns to normal.
At this point, a vague user report finally has an explainable and verifiable technical root cause.
Inviting Another Collaborator
But finding the root cause doesn't mean you've reached the final step of solving the problem.
The engineer can have the agent map out a fix: restore the subscription after reconnection and calibrate the state once when the connection recovers. At the same time, the agent can summarize affected scenarios, scope of changes, validation cost, and temporary workarounds, and then invite the product manager into this session.
What the product manager sees includes the original difficulty the user hit, the clues the operations person extracted from logs, the engineer's process of locating the root cause, and the cost and risk of different approaches.
Based on this information, the product manager can decide whether immediate fixing is needed, how to schedule releases, and how to respond to the user before a fix ships.
Operations brings the field, engineering traces the root cause, and product decides how to proceed.
Judgments from different roles take turns continuing in the same session. The analysis left by one person becomes the starting point for the next person to probe, eventually turning a user report into a well-founded handling decision.
Collecting Scattered Information
The small change Co² brings corresponds to a long-standing fact in software development: the information needed to understand a problem is often scattered across different people.
A product person knows what business reality lies behind a seemingly odd rule. A tester knows exactly which steps reproduce an intermittent issue. An engineer familiar with the system knows which historical constraints an innocent-looking change might touch.
These judgments are hard to convey with just "help me build the feature."
No matter how much information AI can process, someone still needs to bring the most relevant facts in front of it. So when we discuss how to use AI better, the question worth considering is: how do we make it easier for the people who truly understand the problem to participate in the current work?
That's the entrance Co² tries to provide.
I hope it can be used in pair development, letting another engineer directly join the solution discussion; in remote troubleshooting, letting someone who knows the field add reproduction conditions; and in requirement clarification, letting business judgment enter the implementation process in a timely way.
More Possibilities
Of course, Co² is still an early, independent experimental project.
The code is open source on GitHub, with installers for macOS and Windows. It can be installed via Homebrew and opened, or run directly in the browser.
There are also a few limitations to understand when using it:
The shared session reuses the original execution environment and quota. Every message from a collaborator is actually sent under the sharer's identity, so you need to pay attention to permission control and quota management.
Public sharing goes through a relay with ordinary TLS, without end-to-end encryption. Only invite trusted collaborators, or enable the "internal network only" switch.
When you exit Co², the shared invite link becomes inaccessible, because Co² is designed for immediate collaboration, not as a long-term entry point.
If you're already using Codex with colleagues, feel free to try it and report any issues you run into via GitHub Issues to help build Co² together.
Closing Notes
I hope that as we use AI to improve work efficiency, we can still leave a place for our colleagues.
Let those who understand requirements, those who know the code, and those who spot problems each bring their own piece in and complete a shared collaboration. That is the meaning of a team.
The chair in front of the screen deserves to be moved a little closer.