Guides / Building software with AI agents

How we first set up Claude and Codex in one repository

The first arrangement: Codex built, Claude reviewed, the owner merged, signed and deployed. Verification records, handoff reports and one merge queue.

Engineering note

By Steven Michael Barber · Published October 19, 2026 · Updated November 3, 2026 · 6 min read

For its first few weeks, the agent-driven part of Chimney Top Digital's development ran on one model: Claude, Anthropic's coding agent, working in cloud sessions, with the owner deciding and approving. On October 18, 2026 the owner connected Codex, OpenAI's coding agent, to the same repository. This historical note describes the first arrangement, on October 18 and 19. The reasons for adding a second model are in the why guide, and the changes we made a day later are in the changes guide.

Who did what at the start

The first split was simple:

• Codex built. It took the next items from a written brief: fixes, a new sign-in option for one app, and records of what the owner had done.
• Claude reviewed Codex's larger changes when the owner asked, and kept doing the operations work it already had in progress, such as investigating an alarm. Its first full written reviews were of Codex's design and automation changes in the early hours of October 19.
• The owner was the only gate. Every pull request was merged, every release record signed and every production deploy started by the owner in person.

Nothing about the existing safety checks was relaxed for the new model. Codex's work went through the same continuous integration (CI) jobs, the same merge rules and the same release gate as Claude's always had.

The repository is the only shared memory

Agent sessions do not remember each other. A Claude session cannot read a Codex conversation, and neither can read last week's session of its own kind. Anything said only in a chat is lost when that chat is archived. So the rule, which we already had for parallel Claude sessions, became central: if it matters, it goes in the repository the same day.

• Decisions go in a dated decisions file, with the question, the options, the owner's answer and what changes as a result.
• Owner steps, such as an account opened, a setting changed or a release signed, go in one running log with the date.
• Open questions for the owner go in a QnA MD file, so the answers are stored next to the questions. See why we built QnA MD.

Before telling the owner what is done or still open, an agent reads the current main branch, not its own copy, which may be days old. Other sessions record things in parallel, and the newest dated entry wins.

Handoff reports

When work passes from one model to the other, or from one day to the next, the outgoing side writes a handoff report in the repository. Codex's first report had five parts, and we kept the shape:

1. Done, each item with its pull request, commit and the evidence that it worked, such as a CI run or a deploy result.
2. Open or blocked, each with the exact next step and who it waits on.
3. Owner steps reported and recorded, so nothing the owner did lives only in a chat.
4. Decisions or questions for the owner, each with a recommendation and the alternative.
5. Surprises and corrections: places where the brief it was given turned out to be wrong.

The last part matters most for a two-model setup. A handoff written by one side is a claim, and the receiving side checks it against the code and the run logs instead of trusting it.

Verification records before every production deploy

The release process required a verification record. The full CI suite ran on the exact commit on the main branch and wrote the record itself: test totals by level, a verdict and a link to the run. A verifier, usually an agent, copied the record into the repository and filled in its row. The owner then signed as approver.

The deploy job checks that record before it touches production. It refuses a record for a different commit, an unsigned record or a failing verdict. If anything other than records has changed since the verified commit, the release needs a new full run and a new record. The record can be read later to see exactly what was tested and who approved it.

One merge queue for parallel sessions

Several sessions often work at once, and their pull requests touch the same shared files: the package lock file, the spelling word list, the third-party license notices and a few indexes. Merged in random order, each merge breaks the next pull request. So changes merge one at a time:

• Before merging, a session checks whether other build pull requests are open.
• Only the pull request at the head of the queue brings in the latest main branch, fixes conflicts with the repository's own tools, runs the checks and pushes. Everyone else holds.
• Follow-up fixes go in a new pull request at the end of the queue.
• Documentation-only changes that touch none of the shared files can merge out of order.

Adding Codex did not change this. It became one more session in the queue.

Worked example: Codex's first release

Codex's first day started with a broken deploy. Early on October 18 a calculators release passed CI, the owner signed its record and the deploy went out. The production smoke tests that run after a deploy then listed 434 checks: 350 passed, 82 were skipped by design, and 2 failed. Both failures were on the help page, which was expected to show a "Free courses" section.

The written brief Codex was given asked for this fix and suggested an approach. Codex checked the brief against the code and the run logs and confirmed the cause: CI built the site with four practice lessons marked as reviewed, which production does not have. So the help page was right in production, and the test expectation was wrong. Codex changed the checks so they expect the section only when the build actually publishes course content, and added a CI step that also builds without those lessons and runs the help checks again on desktop and mobile.

The steps that followed show the first arrangement:

1. Codex opened the fix. CI passed all 20 jobs, and the owner merged it.
2. The owner started a full CI run on the main branch: all 20 jobs passed, with 9,795 tests passed, 0 failed and 3 skipped.
3. Codex copied that run's own record into a pull request, filled in the verifier row and left the approver row blank.
4. The owner signed the approver row, merged the record and started the production deploy.
5. The deploy's smoke run listed the same 434 checks: 352 passed, 0 failed, 82 skipped.

Codex's handoff report then listed what the brief had gotten wrong. The brief said the failed deploy had 432 passing smoke tests; it had 350 passed, 2 failed and 82 skipped. It also assumed CI ran the quizzes in preview mode, when it actually used production mode plus the four reviewed lessons. And the helper the brief suggested could not be loaded by the browser test tool, so the fix used the plain function underneath it.

Two features of the setup stand out here. First, the owner did all the merging, signing and deploying. That was safe, but every step waited for the owner. Codex's pull requests that day took between 31 minutes and about four hours from opening to merge. Second, the corrections in the report came from checking claims against evidence, not from accepting the brief. Both points shaped what we changed next.