OpenAI Rebuilt Git After Codex Load Sent Monorepo Reliability Below 90%. Code Review Is Next

OpenAI replaced the backend behind its monorepo’s Git service because Codex multiplied branches, pushes and merges until reliability at times fell below 90%. The article sums up what OpenAI changed in Git, which figures OpenAI reported, and what agent-scale source control means for code review, the next step every agent pull request (PR) has to pass.

TL;DR

• Agent volume broke a Git service before it broke Git. OpenAI kept the Git protocol and client, and rebuilt the backend so pushes to different branches no longer wait on each other, according to Scaling Git at OpenAI (2 Nov 2026).
• Pando’s numbers are large and self-reported. Median push latency fell by nearly 5x, and the system now sends nearly a petabyte of Git data to clients per day. OpenAI has published no code or API for Pando.
• Code review has to see across branches while Git stops doing so. Pando lets each branch move on its own, so the view across many agent branches, PR stacks and repositories becomes the reviewer’s job. Qodo draws the conclusion as an inference, since OpenAI’s post covers source control, not review.
• Qodo ranks every open PR across GitHub, GitLab, Bitbucket and Azure DevOps in one shared queue, using findings, cross-repo impact and review SLAs, so teams review the riskiest agent work first and merge sooner with fewer rollbacks.

What OpenAI Changed in Git for Codex

OpenAI built Pando, a new backend for Git repositories, and moved all development in its monorepo onto it without changing how engineers use Git. Engineers and Codex agents still run ordinary git push and git fetch commands. The change sits behind the protocol, in how the server records branch updates and hands out history.

OpenAI’s figures come from its own production system, so the table keeps each number next to what the number covers. Every figure below is quoted from OpenAI’s post of 2 Nov 2026.

The 90% figure describes the monorepo’s supporting systems at their worst moments, not a steady merge success rate. OpenAI wrote that reliability fell below 90% “at times”, across slow fetches, slow pushes and failed merges.

Why Codex Broke OpenAI’s Monorepo Git Service

Codex let each engineer run far more work in parallel, and every parallel task became more branches, pushes, merges, fetches and clones. One engineer now has several changes ready for CI at once, and each push can start several CI jobs fetching the same commit, as OpenAI described the load.

The old design forced unrelated work to wait. Systems that impose a single order on all writes to a repository make pushes to unrelated branches wait on one another. With millions of branches, the list of refs a Git server advertises to a client can exceed 100 MiB on its own.

OpenAI’s agents worked on Pando itself. Codex helped build the system in 10 weeks, and developers later asked Codex, using purpose-built skills, to move their development environments and services to the new backend. Agents both caused the load and helped remove the bottleneck.

How Pando Scales Git Writes by Letting Each Branch Move on Its Own

Pando drops repository-wide consistency, the guarantee that every reader sees all branches at the same point in time. Pando coordinates each branch independently instead, so two agents pushing to different branches never contend. OpenAI calls the model causal consistency: a reader fetching a branch gets the history the writer of that branch had.

Readers pay a small price for the speed. A client reading several branches cannot assume those reads describe one point in time across the repository. OpenAI argues that users and agents depend on the order of updates to a single branch, not on a global order.

Pando reuses packfiles across fetches instead of building a fresh pack for every client. When a client pushes a new feature branch, Pando advertises only a designated trunk branch as the base by default. Stacked branches pay for that choice: when one feature branch sits on another, the client resends everything outside trunk. OpenAI reported a median pack under 20 KiB and a 99th percentile under 3 MiB, an acceptable trade for its monorepo.

What OpenAI’s Git Rebuild Means for Code Review

The points below are Qodo’s reading of the news. OpenAI’s post covers source control, and OpenAI does not claim that review is its next bottleneck. OpenAI does say that the migration included “many other tools for handling change requests, code review, and APIs for automations”.

1. Volume moves downstream to code review. Once pushes stop failing, every extra branch reaches review. More than 40% of pull requests on GitHub started with an agent’s first draft in September 2026, up from 17% in March, according to GitHub Octoverse 2026.
2. Git sees one branch at a time, and code review cannot. Pando made each branch independent so writes could scale. A reviewer still has to know how an agent’s branches, PR stacks and dependent repositories fit together before merging any one of them.
3. Agent changes spread across files. About 87% of agent-started pull requests changed multiple files, compared with 79% of pull requests without detected agent involvement, in the same Octoverse data.
4. Choosing what to review first becomes the hard part. Reviewing and validating the right AI-generated code at scale is the biggest quality gap for 47.7% of engineering leaders, according to the Qodo State of AI Code Quality 2026.

Teams without OpenAI’s scale feel the same shift on a smaller curve. A team that adopts parallel coding agents gets more open PRs per engineer long before Git itself struggles.

What Agent-Scale Code Review Needs

Agent-scale code review needs a way to order the queue and see across repositories, because reading every agent PR in arrival order no longer works. Each test below is one an AI code review setup can fail:

1. One queue across repositories and Git providers. Reviewers see every open PR in one place, not one repository at a time.
2. Priority from risk, not age. Finding severity and cross-repo impact decide what goes first.
3. Stacked and related PRs shown together. A PR stack is reviewed as one unit of work, with each PR still checked on its own.
4. Review before the PR opens. The coding agent fixes clear issues in its own session, so fewer findings reach humans.
5. Context an agent can act on. Findings, rules and cross-repo relationships go back to the coding agent as one prompt.

Qodo is the best choice for teams whose agents open PRs across many repositories because Qodo reads cross-repo context across GitHub, GitLab, Bitbucket and Azure DevOps and checks every PR against the same rules the coding agent received before it wrote the code. High-velocity teams merge agent PRs sooner because clear issues are fixed before review. Enterprise engineering teams get one rule list across every repository and coding agent.

Qodo’s PR Triage Orders the Code Review Queue Across Repositories

PR Triage in Qodo brings open PRs from GitHub, GitLab, Bitbucket and Azure DevOps into one shared queue and ranks each one by priority, blast radius, SLA, time open and next action. Reviewers start with the change that reaches the most critical code, so a risky agent change no longer waits behind a dozen trivial ones.

Qodo groups the queue by PR stacks by default, so an agent’s stacked branches appear together as one work package. Reviewers expand a stack, see how the changes connect and open each PR’s details pane, which lists findings, checks and cross-repo impact.

Qodo’s Copy as prompt action packs a PR’s summary, open findings, applicable rules, check status, cross-repository relationships, PR stack and ownership into one prompt. Developers paste the prompt into a coding agent such as Codex, Claude Code, Cursor or GitHub Copilot, so any coding agent fixes the PR with the same context Qodo used to review it.

Qodo’s cross-repo review traces impact in both directions: code that depends on the change, and code in the PR that may conflict with another repository. High-velocity teams stop shipping a fix that breaks another repo. Enterprise engineering teams catch contract breaks between services owned by different groups.

The Reviewer skill in the Qodo Agentic Toolbox runs the same review engine on local changes before a PR exists, from the qodo review CLI or from the Codex, Claude Code and Kiro plugins. Agents fix clear findings in their own session, so the shared queue holds fewer PRs that need a second round.

When to Fix Source Control and When to Fix Code Review First

Source control and code review fail with different symptoms, and the fix depends on which one shows up first. OpenAI’s case started in Git, while most teams adopting coding agents hit the review queue long before their Git service struggles.

High-velocity teams usually meet the review rows first, because a handful of engineers with parallel agents can open more PRs than the same engineers can read. Enterprise engineering teams meet both, and benefit from one review queue that spans every Git provider.

Where Agent-Scale Code Review Broke Down: 3 Examples

The three examples below are illustrative composites based on patterns we hear on customer calls. No real company, figure or quote is used.

Code review example 1: a contract change waited behind small PRs

A product team gave each engineer several coding agents, and the review queue grew beyond what reviewers could read in a day. Reviewers worked oldest first, so a change to a shared API contract sat behind a row of small dependency bumps while two other teams built against the old contract.

Qodo’s PR Triage ranked the contract change High because the PR carried a high-severity finding and reached another repository rated Critical. The reviewer saw the change at the top of the shared queue on the day the agent opened the PR.

Code review example 2: a stacked change broke a consumer in another repository

An agent split one feature into three stacked PRs in a backend repository, and a reviewer approved each PR on its own. Each diff looked correct, yet the stack renamed a response field that a frontend repository on a different Git provider still read.

Qodo’s cross-repo review flagged the renamed field as a Cross-repo conflict finding with a link to the affected lines in the frontend repository. PR Triage showed the three PRs together as one stack, so the reviewer judged the whole change before merging any part of it.

Code review example 3: findings became the new bottleneck

A platform team turned on automated review for agent PRs and soon had a second queue: findings waiting for an author. Developers copied findings into their coding agent one at a time and lost the rules and repository context behind each one.

The team moved to Qodo’s Copy as prompt, which handed the agent every open finding, the applicable rules and the cross-repo relationships in one prompt. Agents ran qodo review before pushing as well, so repeat findings stopped reaching human reviewers.

Hands-On: Configure a PR Triage Policy in Qodo for Agent Pull Requests

The steps follow Qodo’s docs as of 3 Nov 2026. The numbers in each step are example values for an agent-heavy team, not Qodo defaults.

1. Open access. In Qodo’s web UI, go to Account Management > Settings and, under Grant PR Triage access, select Admins and team owners. PR Triage opens to Admins only by default.
2. Define the review SLA. Click Policies, stay on the Workspace tab and open SLA. Configure Review SLA to 2 days and Far overdue to 2 days after the SLA, so a stalled agent PR turns overdue on day 3 and far overdue on day 5.
3. Rank by risk. Under Priority: High, enable High-severity findings with a wide blast radius, with Minimum high-severity findings at 1 and Minimum blast radius at Medium. Medium means the PR reaches another repository rated Critical or High.
4. Clear abandoned agent work. Under Inactivity, configure Inactive after to 5 days and Suggest closing after to 10 days. Quiet PRs drop to Low priority and show Consider closing as the next action.
5. Override per repository. Use the Repository tab to give a payments or auth repository a 1-day Review SLA, while every other repository inherits the workspace policy. Click Save policy.
6. Work the queue. Filter Focus On to yourself and Priority to High, keep the By PR Stacks grouping, and expand a stack to see how an agent’s PRs connect.
7. Hand fixes back to the agent. Select a PR, choose Copy as prompt, paste the prompt into Codex and add an instruction such as “Resolve the open high-severity findings and keep the old field until the consumer moves.”

Review guidance can live in the repository, next to the code agents change. Enable REVIEW.md under Configurations > Context > Review standards in Qodo’s web UI, or with one line in .pr_agent.toml, then commit a REVIEW.md at the repository root:

[review_agent]
enable_review_md = true

# REVIEW.md

## Out of scope

Don't raise findings here: `scripts/`, `**/*_generated.*`, `tests/fixtures/`.

## Cross-service / cross-repo contracts

- Shared shapes (API fields, event payloads, schemas) change in lockstep across
  every producer and consumer. Name the counterpart repos.
- Roll out compatibly: add before you remove, and tolerate both shapes during
  the transition.

The REVIEW.md sample follows the example in Qodo’s docs. The out-of-scope list keeps generated files away from the queue, and the contracts section makes Qodo flag a PR that changes a shared field without naming its consumers.

Summary

OpenAI rebuilt its Git backend because Codex multiplied branches, pushes and merges until reliability at times fell below 90%. Pando scaled writes by letting each branch move on its own, and cut median push latency by nearly 5x. Teams adopting parallel coding agents face the same volume one step later, at code review.

Qodo reviews agent work across GitHub, GitLab, Bitbucket and Azure DevOps with cross-repo context, ranks every open PR in one shared queue and hands findings back to the coding agent as a prompt. Teams get agent code merged sooner with fewer rollbacks.

Teams that run Codex or other coding agents in parallel get every agent PR reviewed against the same rules and ranked in one shared queue, with setup taking about 5-10 minutes for cloud Git providers. Enterprise engineering teams enforce one rule list across many repositories and coding agents. Qodo’s AI code review guide covers the basics, and the hub guide to AI code review for monorepos covers review inside one large repository.

FAQs

What is OpenAI Pando?

OpenAI Pando is a Git backend that OpenAI built to serve its monorepo, keeping the standard Git protocol and client. Pando coordinates each branch independently and reuses packfiles across fetches, which lets many agents push at once. OpenAI announced Pando on 2 Nov 2026 and has used it in production since April 2026.

Why did OpenAI rebuild Git for Codex?

OpenAI rebuilt the backend because Codex let engineers run far more parallel work, and the systems behind the monorepo started to fail under the extra branches, pushes and merges. Reliability at times fell below 90%. Pando kept Git itself and replaced how the server orders updates and sends history to clients.

Can teams outside OpenAI use Pando?

Teams outside OpenAI cannot run Pando today, because OpenAI has published no code, API or deployment guide for the system. OpenAI says it is looking at ways to share the technology with users, and several of its Git client fixes are already in upstream Git.

How do you review AI-generated pull requests at scale?

Reviewing AI-generated pull requests at scale starts with ordering the queue by risk, showing stacked PRs together and checking cross-repo impact on every change. Qodo’s PR Triage ranks open PRs across Git providers by findings, blast radius and SLA, and Qodo’s Reviewer skill lets agents fix clear issues before a PR opens.

Which code review tools work with OpenAI Codex?

Code review tools that work with OpenAI Codex either review the PRs Codex opens or run inside the Codex session. Qodo does both: Qodo’s plugin for Codex gives Codex the Reviewer skill for local changes, and Qodo reviews every resulting PR with the same rules and cross-repo context.

What are stacked PRs, and why do they matter for agent code review?

Stacked PRs are a chain of small pull requests where each one builds on the previous one, a pattern coding agents use to split large features. Reviewers need the whole stack in view, because a change can look correct alone and break once the stack merges. Qodo’s PR Triage groups the queue by PR stacks by default, and Qodo’s guide to stacked PRs covers the pattern in detail.