When I’m writing in Claude Code, sometimes I want the Codex chat I use for fact-checking to verify a number. On my Mac, I can now ask without leaving the conversation:
Ask the Codex fact-checking chat to compare the numbers in this table with the original source. Bring the result back here.
That’s an illustrative request, not a quote from a real chat. It goes to a conversation I already use, not a new one created for the task. The result comes back to the Claude Code chat where I asked.
The review itself still takes work. What I wanted to cut was the trip in between: find the other conversation, write the request again, then paste the answer back into the chat where I was working.
Why I wanted to use the chats I already had
The conversation where I’m drafting an article isn’t always the best place to verify the evidence. Another chat may already have worked through the source material or the decisions behind it. That’s why I want that particular chat, not just a different model.
I used to open it myself, explain what to check, then carry the answer back. With enough trips between chats, it’s easy to have the answer in one place and forget to use it in another.
I previously wrote about running a one-off code review between Claude and Codex. That was about getting a second opinion on one change and closing out the review. This time I wanted to hand a small task to an existing chat while keeping the main work where it was.
The request names a chat and says where to return the result
I specify the chat name, the material to check, the scope of the work, and what I want back. I don’t have to create a tracking ID or type a command each time. If the name matches more than one chat, the handoff stops for clarification instead of guessing.
Starting chat → Named chat → Save the result → Retrieve it in the starting chat
From Claude Code, I can send one fact-check to the appropriate Codex chat. In the other direction, I can ask a Claude Code chat to review a change and bring the findings back to Codex. The handoff carries what the task needs. It doesn’t copy the entire conversation history; each chat keeps its own context.
If a number turns out to be unsupported, I can decide whether to remove it or look for a better source while the draft is still in front of me.
What I tested in each direction
With an early version of the bridge, I sent a code review in one direction and a request for fixes in the other. The results came back and were checked against the changes and tests before the fixes were accepted. An acknowledgment wasn’t enough to close the task.
I later tested requests by chat name in both directions. Separately, I tried a single read-only request with two chats I already used for everyday work. The Claude Code chat answered, and I verified and retrieved that answer in the Codex chat that initiated the request.
Those were separate checks. They don’t establish that every chat or every kind of request will behave the same way.
A notification is not the result
A notification can be sent before the other chat has taken the job. And a result can be saved before anyone has read it in the chat where the request started. Treat those as a single “done” and it’s hard to tell where to pick up.
I separate the notification, the acceptance of the task, the saved result, and retrieval in the original chat. I count the result as returned when the opening chat matches it to the request and reads it. Deciding whether the findings are right, or whether to apply a fix, is a separate step.
If a reply doesn’t appear, I check the original request before creating another one. If the other chat has finished, the job is to retrieve the saved result, not make it do the work again. I tested that recovery path in a simulation; I didn’t observe it recovering from an actual notification outage.
I drew the same distinction between saving a report and reading it in a separate experiment with dot and Codex.
One review after three hours, with the receiving chat already prepared
On November 10, 2026, I prepared an existing Claude Code chat to receive a request and left it out of the foreground for three hours. Both tools ran on the same Mac under the same OS user. I then sent one code review from Codex. Claude Code saved the findings, and the originating Codex chat matched them to the request and retrieved them.
A local process handles the wait. It’s not designed to call a model at regular intervals while idle. Models still do work when a request arrives and when a result is read and reported. I didn’t measure billed token usage, so this test doesn’t establish that waiting costs nothing.
On November 14, I put the Mac to sleep manually. Once it woke, I verified that the same receiving process was still running, then completed another round trip. That was delivery after wake, not during sleep. I didn’t establish unattended recovery after quitting the app, restarting the computer, or stopping all receivers.
Start with one read-only request
“Can you check this?” doesn’t say what success looks like. Here’s a fuller version of the fictional request from the opening:
Ask the Codex chat named “Fact-checking” to compare only the three specified rows with the original source I provided. Read and compare only; don’t edit, publish, or send anything outside this workflow. Return which numbers match, which don’t, the relevant source passages, and anything you couldn’t verify to this Claude Code chat.
If the source can’t be opened, leave the number unverified. A useful answer identifies what’s missing rather than filling the gap with a guess.
OpenAI’s Codex plugin for Claude Code documents using Codex from Claude Code for code review or task delegation. Anthropic’s Claude Code Channels documentation describes delivering events to a running Claude Code session. I consulted both on November 14, 2026. They describe their respective features; the round trips here are observations from my own setup.
The biggest change for me is where I pick up the work. I can ask another chat to check something, then read the answer where I need to use it. If you already switch between the two tools, start with one task whose answer you can verify. Decide where the result should land before you send it.
Originally published in Japanese on November 14, 2026.