OpenAI Codex architecture,
read from the code.
603,461 lines of source, 11,461 parts described, 30 areas and 30 customer paths. A coding agent, in Rust. Every line on this page comes from the model — open it and check any of them.
What the model holds.
The 14 heaviest areas of 30.
| Area | Screens | Actions | API | Records | What it covers |
|---|---|---|---|---|---|
| Agent core | 0 | 1,143 | 0 | 2 | Runs the agent turn: builds the model context, streams the response, dispatches tool calls, and decides when a turn is finished or must be compacted. |
| Sandboxing and approvals | 0 | 764 | 0 | 121 | Confines what a command may read, write and reach on the network, and asks the user to approve anything the policy will not grant on its own. |
| App server | 0 | 420 | 172 | 206 | The JSON-RPC service that the IDE extensions and the desktop app drive Codex through; the versioned contract every non-terminal client speaks. |
| Plugins | 0 | 576 | 0 | 125 | Installs, enables and updates third-party plugins from a marketplace, and loads what they contribute into a session. |
| Model providers | 0 | 448 | 0 | 94 | Chooses and talks to the model backend - OpenAI Responses, Chat Completions, realtime, Bedrock, Ollama, LM Studio - and keeps the catalog of… |
| Networking | 0 | 510 | 0 | 0 | Every outbound connection Codex makes and the proxy that enforces the network policy on commands running inside the sandbox. |
| MCP | 0 | 492 | 1 | 7 | Connects Codex to Model Context Protocol servers so their tools and resources appear to the model, and exposes Codex itself as an MCP server. |
| Code mode | 0 | 432 | 11 | 40 | Lets the model write code that calls tools directly instead of emitting one tool call at a time, executed against a sandboxed runtime. |
| Headless exec | 0 | 371 | 35 | 63 | Runs Codex non-interactively for scripts and CI, and hosts the process/relay server that executes work on a remote or foreign machine. |
| Authentication | 0 | 378 | 11 | 77 | Signs the user in with their ChatGPT plan or an API key, stores the credentials, and refreshes them for every request. |
| Telemetry | 0 | 436 | 0 | 2 | Records what happened in a session as analytics events, OTEL spans and diagnostics, and collects user feedback on a turn. |
| Terminal UI | 420 | 0 | 0 | 0 | The interactive terminal experience: the composer, the transcript, approval prompts, pickers and status surfaces that a developer works in. |
| External agent migration | 0 | 316 | 0 | 1 | Imports configuration and past sessions from other coding agents so a user switching to Codex keeps their history. |
| Skills | 0 | 263 | 1 | 33 | Discovers reusable instruction packs on disk and in plugins, and offers the relevant ones to the model for the task at hand. |
What a person walks through, step by step.
30 paths are described in the model; the longest 12 are here, with how many areas each one crosses.
The core loop: a prompt is accepted, context and tools are assembled, the model is sampled, its tool calls are dispatched and streamed back as transcript items, and the…
What happens when a command the model asked for is not allowed to run as-is: the policy decides, the first attempt runs sandboxed, a denial turns into an approval…
The browser OAuth flow: Codex starts a loopback server, sends the user to the authorize page, exchanges the returned code for tokens, checks the account is allowed to…
How a folder of Markdown becomes something the model can call: roots are resolved and parsed into a catalogue, the catalogue is rendered into the prompt, and an explicit…
Working with a task that ran in the cloud: the browser lists them, one is opened and its attempts compared, and the chosen patch is preflighted and then applied to the…
A non-interactive run: the prompt comes from argv or stdin, codex exec drives the same app-server protocol a UI would, answers the server's approval requests from policy…
Walks the user's Claude Code or Cursor setup - home first, then each open repository - and offers one migration item per artifact that would actually change Codex, so…
Applies the items the user ticked one at a time, never overwriting anything Codex already has, and keeps going after a failure so one bad item cannot cost the rest of…
From browsing the catalogue to a plugin that actually contributes: the source is materialised into the plugin store, config.toml is given an enabled entry, and the…
How an editor extension holds a Codex session: it opens a connection, negotiates the protocol, subscribes to a thread, and from then on receives every item and status…
The two-phase memory pipeline: eligible threads are sampled into per-thread extractions, and a single global consolidation agent merges them into the memory files the…
How an apply_patch tool call becomes a change on disk: the hunks are parsed and turned into a file-level plan, the write permissions for exactly those paths are worked…
What the product enforces on its own.
12 rules are described; each one watches a record and changes something else when it moves.
Every terminal turn folds its usage into the thread's running totals, which is what the context-remaining meter and the usage card are drawn from.
Compaction is not asked for; it is triggered by the running token total getting close enough to the model's context window that the next call would not fit.
The account's standing against its usage limits is never polled during a turn - it is read out of the headers the model response already carries.
Everything a session produces - model items, inter-agent messages, compaction records, turn context, world state and protocol events - is appended to the rollout as it…
Installing, uninstalling, enabling or disabling a plugin does not just change a config value - it re-derives everything the session takes from plugins, because skills,…
A goal is not just a note - every model call's usage accrues against it, and it is this accrual, not any explicit action, that eventually stops the goal.
Marking a thread polluted is not enough on its own: if that thread was part of the last consolidation baseline, its material is already in the memory files and a fresh…
A saved session needs a name a person can recognise in a list, so the first user message triggers a generated title rather than the list showing a uuid.
The states records move through.
CollabAgentStatusEntry · Multi-agent
Sub-agent status
Pending init → Running → Completed → Errored → Interrupted → Shut down → Not found
7 states · 14 transitions
CommandExecutionApprovalDecision · Sandboxing and approvals
Command approval decision
Pending → Accept once → Accept for the session → Accept with an execpolicy amendment → Apply a network policy rule → Decline → Cancel
7 states · 6 transitions
McpServerStatus · MCP
MCP server connection
Not started → Starting → Connected → Authentication required → Failed → Cancelled → Disabled
7 states · 10 transitions
ThreadGoal · First-party extensions
Thread goal status flow
Active → Paused → Blocked → Usage limited → Budget limited → Complete
6 states · 12 transitions
TurnAttempt · Cloud tasks
Cloud turn attempt
Unknown → Pending → In progress → Completed → Failed → Cancelled
6 states · 5 transitions
RemoteInstalledPluginsCache · Plugins
Remote installed-plugin reconciliation
Empty → Claimed → Reconciling → Published → Abandoned → Cleared
6 states · 8 transitions
Answers nobody wrote down.
Computed from the model’s own connections, with the count behind each one.
How much of this product is built but unused?
59% of this product's API surface is dark: built and paid for, but part of no described customer path and consumed by no screen.
140 OF 237 ENDPOINTS · READ FROM 30 CUSTOMER PATHS DESCRIBED SO FAR
Where is it riskiest to make a change?
The riskiest place to change is “Terminal UI”: more of the product depends on App than on anything else.
242 INBOUND DEPENDENCIES · COMPUTED FROM THE REACH GRAPH, NOT ESTIMATED
Where did the engineering effort actually go?
The deepest engineering investment is “Agent core” — 11% of the product's mass. “Session storage” is compact and self-contained: the cheapest place to change.
1216 VS 59 OBJECTS · CHANGE-COST RATING = SIZE × CROSS-DOMAIN COUPLING
Which customer experience breaks first?
The most fragile customer experience is “Start a new thread”: it crosses 8 domains in 17 steps — the first place integration breaks.
INTEGRATION-TEST PRIORITY №1 · DOMAINS COUNTED PER PATH STEP
Does the product lean on any one part?
One subsystem — App server wire protocol — alone carries 223 core objects. The product leans on it.
CONCENTRATION RISK · COUNTED FROM OWNERSHIP LINKS
Ask the model your own question →How these answers were scored →
About this model.
GitMir read the public repository and established what the product does: its areas, screens, actions, API routes, records, customer paths, status flows and rules, with every statement traceable to the source it came from. Nothing on this page is written by hand; it is the published model, as of 2026-08-30.
This page is a snapshot of the published model. On a connected repository the model is updated as commits land, so people and AI agents work from the product as it is now rather than as it was when somebody last wrote it down.
Yes — connect a repository and GitMir builds the same thing for it: features, rules, customer paths and how they connect, available to people on the screen and to coding agents over MCP.