Picture two windows open on one screen. In one, Codex has just finished a chunk of backend work. I read it, I commit it, and then I turn to the other window, where Claude Code is pointed at the very same folder, and I ask it to review what Codex just wrote. Two coding agents, built by two rival companies, working the same code, one handing off to the other. And here is the part that stopped me the first time I really looked at it. Nothing connects them. There is no plugin between them, no bridge, no clever integration I set up over a weekend. They do not talk to each other at all. Neither one knows the other exists.
So how are they collaborating? They are not, not with each other. They are both just talking to the same files. And that is the whole idea, and it is genuinely easy to miss, because it hides in something too ordinary to give a second look. Your code does not live inside Codex, and it does not live inside Claude Code. It lives on your machine, in a folder, as plain files sitting on a disk. The app is only a visitor. A file has no loyalty to the tool that wrote it. It is text in a folder, and any tool you point at that folder can read it, change it, and leave it for the next one.
Point Codex at the folder. Point Claude Code at the same folder. Now two different AIs are working one project, and the folder is the table they are both sitting at. That is it. That is the mechanism.
This is why the phrase that matters is no integration required. Power like this usually has to be assembled. You expect a connector, an API key traded between two services, some brittle glue that breaks the next time either tool updates. There is none of that here, because there is nothing to assemble. It is not a workaround and it is not a hack. Nothing was worked around. It falls straight out of the plain fact that your code is local, and local files belong to you, not to the app of the week. You did not build this capability. You noticed it. It was already true. That is the part I love about it. It is not a thing you do. It is a thing you realize, and the moment you realize it, you are running a team.
Because once two tools can share a folder, you can give them different jobs, and the jobs are where the real gain is.
Claude is the one I reach for on design and the front of the house. It is quick, and it has the better eye for how a thing looks and feels. Codex I send after the heavy backend work, the long grind, partly because on a standard plan right now it gives you more runway before you hit a wall, and partly because it tends to be more thorough on the hard, tangled problems. Those strengths shift from one release to the next, so do not take my word as gospel. Take it as this quarter's weather. But the shape of it has held. One is the sharper designer. One is the stronger long-haul builder.
The third job is the one that matters most, and it is the reason a nervous non-developer should feel better about all of this, not worse. You use the second AI as the reviewer. Here is the oldest rule in any shop that ships real software. Nobody reviews their own code. The person who wrote it cannot see what they missed, because the same blind spot that produced the bug hides it from them on the way back through. A model is no different. Ask the model that wrote the code to check the code, and it brings the very same blind spots to the review that it brought to the work. A different model, trained by a different company on different data, walks in with a different set of eyes. It catches what the first one could not, because it was never going to make that particular mistake to begin with.
So the loop is simple. Codex builds. You read it, and when you are satisfied, you send Claude Code into the same folder and ask it to review the whole thing and tell you what is wrong. It comes back with the list. You either have Claude fix it, or you carry the notes back to Codex. Then you flip the roles and run it again. You are not handing one black box your work and hoping. You are setting two of them against each other, with you holding the pen.