OpenAI’s Pierre Deal Pulls Developers Deeper Into Codex. Where Should Your Code Rules Live?
OpenAI agreed on 4 Nov 2026 to acquire Pierre Computer Company, the maker of the Trees and Diffs libraries that show files and code changes in the Codex app. The deal moves more of the developer workflow, including where people read and edit agent code, into one coding agent’s app. The deal has not closed, the price is undisclosed, and teams that run more than one coding agent now have to decide where their code rules live.
TL;DR
- OpenAI is buying the team behind the screens developers read agent code on. Pierre’s Trees and Diffs already show a project’s files and its changes inside the Codex app, and Diffs lets a developer edit a line inside the diff, according to OpenAI’s announcement of 4 Nov 2026.
- The deal is not closed, and the price is undisclosed. Closing needs regulatory approvals, and OpenAI and Pierre stay separate companies until then. Pierre’s open-source projects stay open source.
- Every coding agent is building its own workspace, and code rules split with the work. Each agent reads its own instruction file, so rules drift between
AGENTS.md,CLAUDE.mdand tool settings, standards slip, and no single place shows what every agent changed. - Qodo reviews every pull request (PR) when it opens, whichever coding agent wrote it, against one
REVIEW.mdper repository plus organization-wide custom instructions, and Codex and Claude Code pull and fix Qodo’s findings through Qodo’s plugins, so teams merge agent-generated code sooner with fewer rollbacks.
What OpenAI Announced About Pierre and Codex
OpenAI announced that it will acquire Pierre Computer Company, Inc., a small developer tools company that builds a Git storage service and open-source libraries for showing code. Developers who have browsed files or looked at a change in the Codex app have already used Pierre’s work, according to OpenAI.
The table keeps each fact next to its source, because the announcement carries no price, user count or other figures.
| What was announced or reported | Detail | Source |
| The deal | OpenAI will acquire Pierre Computer Company, Inc. | OpenAI’s announcement, 4 Nov 2026 |
| Status | Subject to customary closing conditions, including regulatory approvals; the two companies remain separate and independent until closing | OpenAI, 4 Nov 2026 |
| Price | Not disclosed | Axios, SiliconANGLE and InfoWorld, 4 to 6 Nov 2026 |
| Pierre’s libraries in Codex | Trees shows a project’s files; Diffs shows what changed and has an edit mode for changing a line inside the diff | OpenAI, 4 Nov 2026 |
| Code Storage | A service that lets apps store code and track its history using Git; customers keep using it while OpenAI brings its features into Codex | OpenAI, 4 Nov 2026 |
| Open source | Pierre’s open-source projects remain open source, and OpenAI will keep contributing to them | OpenAI, 4 Nov 2026 |
| Team size | “Barely in the double digits” | InfoWorld, 6 Nov 2026 |
| OpenAI’s stated goal | Make Codex “the place where developers and agents take on their most ambitious projects” and connect “the code a company ships with the decisions its people make” | OpenAI, 4 Nov 2026 |

OpenAI tied the deal to Pando, the Git backend it described two days earlier for engineers and agents working in parallel. Qodo’s breakdown of OpenAI’s Pando rebuild covers the source control side.
What Pierre’s Trees and Diffs Do Inside Codex
Pierre’s Trees and Diffs are display libraries that render files and code changes for a developer to read, comment on and edit. Neither library finds issues in code. Diffs is an open-source diff and code rendering library with split and stacked layouts, syntax highlighting, an edit mode and a framework for adding comments and annotations to lines, according to Pierre’s Diffs documentation. Trees is an open-source file tree rendering library.
Code Storage is Pierre’s paid service. App builders use it to keep generated code and other files in Git at large scale, and Pierre lists Lovable, Bolt and Amp among its users on its own site.
The deal targets Microsoft’s GitHub, according to Axios, which wrote that OpenAI is “moving beyond helping developers write code toward controlling more of the infrastructure where that code is stored, reviewed and shipped.” OpenAI’s announcement does not mention GitHub, so the GitHub framing is Axios’s own.
Whoever builds the screen, the code on it still has to meet a team’s rules, and Codex is not the only coding agent building a screen of its own.
Why the Pierre Deal Matters: Every Coding Agent Wants to Be the Only Workspace
Every coding agent vendor is now competing to be the one app where software gets built. OpenAI says it wants to “set the standard for modern software development” from “the first branch an agent creates” to deployment, and Pierre’s libraries move writing, browsing files and editing diffs into Codex. Claude Code on desktop promises to take developers “from writing code to merging PRs in one place,” Anthropic wrote in February 2026. Cursor 3 calls itself “a unified workspace for building software with agents,” and Origin, Cursor’s Git forge in early beta, puts repositories and pull requests next to its agents.
Each pitch assumes a team picks one agent. Most teams don’t. Codex runs on one team, Claude Code on another and Cursor on a third, often across several Git providers.
So every workspace that gets more complete pulls a team’s work further apart. Each agent reads its own instruction file, keeps its own settings and opens PRs from its own app. A rule written for Codex stays in Codex, and nobody owns the rules across all three. The cost shows up in four places.

What Breaks When Code Rules Split Across Coding Agents
- Rule files drift. Codex reads
AGENTS.mdand Claude Code readsCLAUDE.md. A team that adds a rule to one file and not the other ends up with two rule lists that slowly disagree, and neither agent knows what the other was told. - Agents miss standards, and drift widens the gap. Only 34.6% of surveyed developers say agents always follow organizational standards, according to the Qodo State of AI Code Quality 2026. An agent working from a drifted file misses rules it was never given, on top of the rules it was given and skipped.
- Agent volume keeps growing. 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. More agent PRs mean more changes checked against rules that already differ by agent, spread across each Git provider’s own list of open PRs.
- Leaders can’t see across agents. Keeping visibility into what code agents create or modify is one of the biggest quality and governance gaps, named by 38.3% of engineering leaders in the same Qodo survey. With rules and PRs spread across several apps and Git providers, no single place shows which rule fired, where, and for which agent’s change.
All four breaks share one cause. The rules live inside the agents, so the fix starts with moving them out.
So Where Should Your Code Rules Live?
Code rules should live outside any single coding agent, in one review layer that checks every PR, whichever agent opened it and whichever Git provider hosts it, and that every agent can read findings from. A rules layer of that kind needs four parts, one for each break.
- One home for review rules outside every agent’s instruction file, so drift between agent files stops deciding what gets checked.
- The same rules applied on every PR, with findings the agent that wrote the code can act on, so a missed standard gets caught whichever agent missed it.
- Review that keeps pace with agent volume, running as each PR opens and checking new commits against open findings.
- One record for leaders across repositories and PR authors, so they see what was found and what got fixed.
Codex code review, in the sense of checking the code Codex writes, then runs on the same rules as every other agent’s code. OpenAI’s announcement covers developer tools inside Codex and does not mention code rules.
How Qodo Builds One Review Layer Across Every Coding Agent
Qodo, the AI Code Review Platform, is the quality and governance layer for teams moving toward a more autonomous SDLC (software development lifecycle). Qodo answers the four breaks in order: one home for review rules, review on every PR, re-checks on every commit and analytics for leaders.

REVIEW.md and Custom Instructions Give Review Rules One Home
REVIEW.md is a file at the root of a repository that tells Qodo’s review agents what to flag and how to prioritize findings on every PR. Qodo uses REVIEW.md only for its code review agents, not for coding assistants, so the review doesn’t depend on which coding agent wrote the change or which instruction file that agent read.
REVIEW.md instructions have been on by default for Qodo SaaS workspaces since 5 Nov 2026, and single-tenant and on-premises teams turn them on in the Qodo portal. The next review picks up any change to the file.
Custom instructions in the Qodo portal add organization-wide guidance for the Issue finding agent, the always-on agent behind every Qodo review, applied wherever a repository has no configuration of its own. Enterprise engineering teams get one list of review instructions across many repositories and coding agents.
Qodo Reviews Every PR, and Agents Fix the Findings
Qodo runs a review automatically when a PR is opened, reopened or marked ready for review. Specialized review agents flag bugs, security issues and anything that breaks the repository’s REVIEW.md guidance, and each finding explains what needs attention, why it matters and how to move forward, inside the PR.
Review Resolver, an Agentic Toolbox skill available in Qodo’s Codex and Claude Code plugins, lets the agent that wrote the code retrieve Qodo’s findings from an open PR and resolve them. Every finding gets an explicit outcome: fixed with an applied change, skipped with a reason, or reported without changes.
High-velocity teams keep the coding agents they already use and get every PR checked, with setup in about 5 minutes on GitHub or Bitbucket Cloud and no new process.
Every New Commit Is Checked Against Open Findings
Each time Qodo reviews a new commit, it re-evaluates every open finding against the changes made since the finding was raised. A finding counts as resolved when the changes address it, even when the fix lands somewhere else, for example in a new file or in a helper the finding did not mention, so reviewers see only the findings that still need action as agent PRs keep arriving.
Code Review Analytics Shows Leaders How Teams Act on Findings
Qodo’s code review analytics shows admins how teams respond to Qodo findings across PRs, repositories and PR authors. Leaders filter by severity, category and finding type over ranges such as the last 30 or 90 days, see which high-severity findings remain unaddressed, and compare accepted findings across repositories.
Where Multi-Agent Code Rules Break Down: 2 Examples
Code rules example 1: a payments rule lived in one agent’s instruction file
A platform team kept its payments rules in a CLAUDE.md file, because Claude Code was the first agent the team adopted. A second team started using Codex on a shared payments client, and Codex read AGENTS.md, which said nothing about idempotency keys. The Codex change looked correct in the diff and skipped the key on a retry path.
The team moved the idempotency rule into the repository’s REVIEW.md, where Qodo’s review agents read it on every PR. Qodo flagged the missing key on the Codex PR, Codex retrieved the finding through Review Resolver and fixed it, and Qodo marked the finding resolved when it reviewed the next commit.
Code rules example 2: small agent PRs piled up for manual checks
A team running Codex and Claude Code across GitHub and GitLab had a steady stream of small agent PRs, such as dependency bumps and config fixes. Each one waited for a person to read it line by line while the team worked through larger changes.
Qodo reviewed each PR as it opened, and the agent that opened it resolved the in-scope findings through Review Resolver. Qodo marked those findings resolved when it reviewed the next commit, so the team read the open findings first instead of every line.
Hands-On: One Review Setup Shared by Codex and Claude Code
The steps follow Qodo’s docs as of 9 Nov 2026. The payments rule is an example, not a Qodo default.
- Install Qodo on your Git provider. Installation takes about 5 minutes on GitHub and on Bitbucket Cloud, and around 5 to 10 minutes on GitLab and Azure DevOps. Reviews then run automatically when a PR opens. On single-tenant or on-premises deployments, turn on REVIEW.md instructions under Configurations > Context in the Qodo portal.
- Add a
REVIEW.mdfile at the repository root. Plain Markdown works, with no required schema.
# REVIEW.md ## Payments - Every write to the payments API sends an idempotency key, including retries.
- Add organization-wide guidance. In the Qodo portal, go to Configurations, then Custom instructions, add “Every write to the payments API sends an idempotency key, including retries” for the Issue finding agent, and click Save. Portal settings apply organization-wide when a repository has no configuration of its own.
- Install Qodo in Codex. Open ChatGPT on desktop, select Codex, click Plugins, search for Qodo and click + next to it, as the Codex plugin guide describes.
- Install Qodo in Claude Code. Go to Claude plugins, open Browse Plugins, search for Qodo, copy the installation command and run it in Claude Code, as the Claude Code plugin guide describes.
- Resolve findings from either agent. After Qodo reviews an open PR, ask the agent that wrote it to resolve the findings you choose, for example by severity.
Fix all high-severity findings.
- Read the record. As an admin, open Analytics in the Qodo portal, choose Last 30 days, and break the data down by repository, PR author, severity or category.
Summary
OpenAI agreed to acquire Pierre Computer Company, whose Trees and Diffs libraries show files and code changes in the Codex app. The price is undisclosed, and the deal still needs regulatory approval. OpenAI wants Codex to “set the standard for modern software development” from an agent’s first branch to deployment, and other coding agents are building their own paths.
When each agent’s workspace holds its own rules, rule files drift, standards slip, PR volume grows across Git providers and leaders lose sight of what agents change. Code rules belong outside any single agent. Qodo reviews every PR against one REVIEW.md per repository and organization-wide instructions, lets Codex and Claude Code resolve its findings through Qodo’s plugins, re-checks open findings on every new commit and shows leaders the record in analytics.
Teams merge agent-generated code sooner with fewer rollbacks. Enterprise engineering teams get one list of review instructions across many repositories and coding agents. High-velocity teams keep their coding agents, get every PR checked and finish setup in about 5 to 10 minutes on cloud Git providers. Qodo’s AI code review guide covers the basics.
FAQs
What is Pierre Computer Company?
Pierre Computer Company is a small developer tools company that builds Code Storage, a Git-based service for storing code and its history, and open-source libraries called Trees and Diffs. Trees and Diffs show files and code changes in the Codex app. OpenAI announced on 4 Nov 2026 that it will acquire the company.
Has OpenAI closed the Pierre acquisition?
OpenAI has not closed the Pierre acquisition. The deal is subject to customary closing conditions, including regulatory approvals, and OpenAI and Pierre remain separate companies until then. Neither company disclosed the price.
Do Pierre’s Trees and Diffs review code in Codex?
Pierre’s Trees and Diffs do not review code. Trees shows a project’s files, and Diffs shows what changed and lets a developer edit a line inside the diff. People do the reading, and teams that want rules checked on every change add a review layer such as Qodo.
Where should code rules live when a team uses several coding agents?
Code rules should live outside any single coding agent, in one review layer that checks every PR whichever agent opened it. Qodo keeps review rules in one REVIEW.md per repository plus organization-wide custom instructions, and applies them on every PR.
How do you review code that Codex writes?
Reviewing code that Codex writes starts with the same rules every other agent’s code is checked against, on every PR. Qodo reviews each PR Codex opens against the repository’s REVIEW.md and the organization’s custom instructions, and Codex can retrieve and resolve Qodo’s findings through Qodo’s Codex plugin.
How can engineering leaders see what coding agents change?
Engineering leaders can see what coding agents change through review findings rather than through each agent’s app. Qodo’s code review analytics shows admins how teams respond to findings across PRs, repositories and PR authors, filtered by severity, category and finding type.