# The Codex–ChatGPT Pro Workflow Makes Verification the Bottleneck

**The Codex–ChatGPT Pro dual-agent workflow separates implementation from acceptance; it does not prove that one AI system is the strongest coding agent**. Codex can hold the repository, requirements, permissions, and test gates while a ChatGPT Pro conversation acts as an external senior engineer. The important design choice is that the engineer cannot approve its own work.

A personal experiment published on July 28, 2026 described Codex opening three browser tabs and splitting a difficult job into separate conversations. After close to 20 message rounds, it brought the result back to the local repository for gates, end-to-end tests, and documentation. Those numbers document one run. They are not an official benchmark, a repeatable speed claim, or evidence that the combination always beats another model or agent.

What teams can reuse is the control structure: one system builds, another system verifies, and the user retains authority over consequential actions.

![Official Codex product visual showing an engineering task progressing to changed-file review.](https://s4.tenten.co/learning/content/images/2026/07/landing-page-1-4.png)

## Correct the product claims before copying the workflow

The source calls the model “GPT-5.6 Pro” and describes it as a web-only, unlimited benefit restricted to individual Pro subscribers. It also attributes a specific model fallback to network quality. None of those statements should become an architecture or purchasing assumption.

The official name is **GPT-5.6 Sol Pro**. OpenAI announced the GPT-5.6 family on July 9, 2026, with Sol, Terra, and Luna occupying different capability and cost positions. The current [GPT-5.6 in ChatGPT documentation](https://help.openai.com/en/articles/20001354-gpt-5-6-in-chatgpt) lists Sol Pro access for Pro, Business, and Enterprise customers. The model is therefore not exclusive to one consumer plan, and GPT-5.6 access is not limited to a browser surface.

“Unlimited” is also inaccurate. The [ChatGPT Pro plan documentation](https://help.openai.com/en/articles/9793128-about-chatgpt-pro) describes usage allowances and abuse guardrails; current tiers are expressed as five-times and twenty-times allowance levels. A browser conversation and a Codex task are different product surfaces, but lower activity in one meter does not make the entire engineering process free. Teams should read the allowance shown for the actual account, plan, model, and surface they are using.

Finally, there is no official evidence that an “unclean network” deterministically forces a particular smaller model. Model visibility and fallback behavior can depend on plan, workspace controls, rollout state, and available allowance. The reliable check is the model label and account state shown by the product, not an inference from an IP address or connection route.

## Why two agents can be more reliable than one

A single agent has an obvious conflict: it creates the change and then interprets whether the change is good enough. The dual-agent pattern assigns four different responsibilities.

| Responsibility | Codex as lead and verifier | ChatGPT Pro as external engineer |
|---|---|---|
| Repository context | Reads project instructions, Git state, and required gates | Receives only the minimum safe context needed for the task |
| Task design | Defines deliverables, prohibited actions, and acceptance criteria | Researches options, explains tradeoffs, and writes code |
| Integration | Applies work in an isolated tree and reviews the diff | Returns a report, patch, or complete replacement files |
| Final judgment | Runs tests and rejects unsupported claims or unsafe changes | Corrects defects based on evidence and never self-approves |

The [official Codex product page](https://openai.com/codex/) presents multi-agent work, worktrees, review, and testing as core operating patterns. The [Codex plan guide](https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan) also documents parallel agents, skills, automations, and Git workflows. These capabilities make orchestration practical. They do not promise that Codex will operate ChatGPT Pro for every task, and they do not establish a model ranking.

![Official Codex product visual showing the desktop workspace and task surfaces.](https://s4.tenten.co/learning/content/images/2026/07/landing-page-2-5.png)

The pattern works only when the roles have different context and authority. Codex may hold the local repository, working tree, test commands, and permission boundary. The external engineer should receive a minimized source package. Uploading an entire private repository, environment files, browser state, or credentials increases the data boundary without guaranteeing better code.

## The cost moves; it does not disappear

The original experiment began with an observation that Codex usage fell. That can be real while the total delivery cost still rises. A team should track four ledgers.

| Cost | What may fall | What may rise |
|---|---|---|
| Primary Codex usage | Long research and implementation work moves to another surface | Codex still packages, monitors, integrates, and retests |
| Wall-clock time | Three independent tasks can run concurrently | Nearly 20 message rounds add waiting and recovery time |
| Human risk | Agents can preserve evidence and repeat gates | Authentication, model selection, and permission errors remain human concerns |
| Rework | Independent verification catches defects earlier | Poor task boundaries create conflicts that erase the benefit |

Do not evaluate this system with token totals alone. Record elapsed time, accepted-change ratio, first-pass test success, correction rounds, security findings, human intervention minutes, and the number of claims that exist only in a chat window rather than durable evidence.

## A six-stage operating procedure

### 1. Freeze the source baseline

Read the repository instructions, then record the branch, commit, Git status, and any inherited uncommitted work. Without a baseline, the verifier cannot show what the external engineer changed or prove that existing work survived.

### 2. Package the minimum necessary source

Exclude `.git`, `node_modules`, build artifacts, caches, databases, runtime state, browser state, and every environment file by default. Run a secret scan before upload. Record the ZIP size and SHA-256 digest. An external conversation does not have implicit access to the local worktree, so missing context must be described explicitly rather than replaced with an indiscriminate repository dump.

### 3. Convert the request into an engineering contract

The assignment needs background, objective, architectural boundaries, change scope, deliverables, required tests, prohibited operations, and acceptance criteria. “Make it better” does not become safer when it is sent to a second model; it simply multiplies ambiguity.

### 4. Open multiple conversations only for independent work

Three tabs do not imply three-times throughput. Research, independent modules, test design, and documentation may separate cleanly. A shared schema, lockfile, migration, or stateful subsystem usually does not. Save each conversation URL and task fingerprint so work can resume after refreshes or interruptions.

### 5. Apply the result in isolation

Verify the file list, size, digest, and version before applying a patch in an isolated worktree. Run the repository's lint, type checks, unit tests, contract tests, production build, and relevant end-to-end tests. A mocked test proves only the mocked condition; it is not production verification.

### 6. Let only the independent verifier close the task

When a gate fails, return the exact error, file location, correct constraint, and smallest complete repair scope. When the gates pass, preserve reports, logs, and unresolved risks in a durable location. Commit, push, pull request, deployment, and database migration are separate permissions. Passing tests does not expand authority.

![Official Codex product visual showing risk-prioritized code review.](https://s4.tenten.co/learning/content/images/2026/07/landing-page-3-4.png)

## The built-in browser reduces friction, not authentication risk

The [built-in browser documentation](https://help.openai.com/en/articles/20001277-using-the-built-in-browser-in-the-chatgpt-desktop-app) describes tabs, sign-in, downloads, and navigation. It also explains that the built-in browser has its own browser state, while the Chrome extension uses an existing Chrome session. Those are distinct trust paths.

An agent should pause for password entry, account selection, CAPTCHA, passkey, or two-factor authentication. It may operate a page the user has already authorized, but it should never request or persist a password, cookie, verification code, or recovery code. The [ChatGPT Work and Codex overview](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex) positions Codex as a software-development environment with local repositories, terminal access, and tools. That makes it a strong verification surface. It does not justify widening identity permissions.

## Reusable dual-agent prompt

The following is a faithful English translation of the source prompt. It preserves all 14 rules, including dirty-worktree protection, secret scanning, isolated patch application, test gates, and explicit permission boundaries. Add the repository's exact required commands and data-handling policy to the acceptance criteria before using it.

```text
I am already signed in to ChatGPT Pro in the Codex built-in browser.

Use dual-agent collaboration for this task:

- ChatGPT Pro is the external senior engineer responsible for deep research, solution design, and writing code.
- You, Codex, are the accountable lead responsible for understanding the request, inspecting the repository, preparing source, assigning work to ChatGPT Pro, monitoring progress, challenging errors, applying the code, and independently verifying the result.
- Do not treat ChatGPT Pro's conclusions as correct by default. You decide whether the work passes based on the source, test results, and acceptance criteria.

Complete the entire process autonomously under these rules:

1. First read AGENTS.md, CLAUDE.md, README, package.json, and relevant architecture documents in the repository. Understand the project constraints, runtime, and mandatory gates.
2. Inspect the current branch, Git status, and source baseline. Do not overwrite or lose existing changes.
3. Package the source required for this task safely as a ZIP:
   - Include the source needed for the current task by default.
   - Exclude .git, node_modules, build output, caches, databases, runtime state, and browser state.
   - Do not include .env files, API keys, tokens, private keys, cookies, or any other credentials.
   - Run a secret scan before upload, and record the source commit, archive size, and SHA-256.
4. Do not assume ChatGPT Pro can access local files, private repositories, or internal environments. Provide all necessary code and context through the archive and task description.
5. Rewrite my request as a detailed, professional, verifiable engineering assignment before sending it to ChatGPT Pro. Include at least:
   - Background and objective.
   - Current architecture and boundaries that must not be broken.
   - Research and change scope.
   - Explicit deliverables.
   - Required tests.
   - Operations that are prohibited or may not be claimed.
   - Acceptance criteria.
6. If the request contains multiple independent complex tasks, create a separate ChatGPT Pro conversation for each task to prevent context contamination.
7. ChatGPT Pro may need a long time. Do not hurry, interrupt, or resend the task simply because it runs for a while. Only inspect the page, reopen the conversation, or ask it to continue from the last completed point after a reasonable wait and repeated checks show no progress.
8. Save the link for every ChatGPT Pro conversation. Recover the task autonomously after a refresh, context truncation, or connection interruption. Do not make me handle intermediate technical problems.
9. After ChatGPT Pro delivers, verify the work independently:
   - Check that the report, patch, source, and attachments are complete.
   - Verify versions, official documentation, and source-level conclusions.
   - Verify file sizes and SHA-256 digests.
   - Apply the patch in an isolated worktree.
   - Review security boundaries, dependencies, lockfiles, and executable flows.
   - Run the repository's required lint, type checks, unit tests, contract tests, production build, and relevant end-to-end tests.
   - Do not describe mocked tests as real production verification.
10. If you find a defect, give ChatGPT Pro the specific evidence, error log, file location, and correct constraint. Ask for the smallest complete repair. Continue the discussion and verification until the work passes or an external blocker is confirmed.
11. Discuss technical issues with ChatGPT Pro autonomously. Do not make me a messenger or ask me about ordinary implementation choices. Make reasonable decisions that do not diverge from the request.
12. If sign-in expires or you encounter account selection, CAPTCHA, password, passkey, or two-factor authentication, pause and notify me so I can complete it. Never ask me for a password, cookie, verification code, or recovery code.
13. After verification passes, preserve valuable reports and evidence in the repository or another durable location. Do not leave them only in a ChatGPT conversation or temporary directory.
14. In the final report, include:
   - ChatGPT Pro conversation links.
   - Source archive baseline and SHA-256.
   - Actual changes made.
   - Defects ChatGPT Pro was asked to repair.
   - Independent test results.
   - Risks that remain unverified.
   - Whether the code is only modified locally or has been committed, pushed, or deployed.

Permission boundary:

- You may read the repository, package source, operate the built-in browser, communicate with ChatGPT Pro, modify local code, and run tests.
- Unless I explicitly authorize it in this request, do not commit, push, create a pull request, deploy, migrate a database, change production configuration, enable production functionality, or operate on real user data.
- Do not widen permissions merely because ChatGPT Pro recommends an operation.

I do not need to take action during the process except for sign-in, verification challenges, or a major product decision that truly requires me. I only need progress and the final result.

My request:

<Describe the request here>

Required acceptance criteria:

<List the functional, test, performance, compatibility, or visual criteria here>
```

The source also provides this optional, separate authorization sentence. It authorizes a push only after verification; it does not authorize deployment or a database migration.

```text
Additional authorization for this task: after every acceptance gate passes, commit the changes and push them to the remote main branch. Deployment and database migration are not authorized.
```

## Frequently asked questions

### Is “Codex directing ChatGPT Pro” an official product feature?

It is not an official feature with that name. It is a user-designed workflow that combines Codex repository access, browser operation, multiple tasks, and verification. Official materials support those component capabilities but do not promise automatic ChatGPT Pro orchestration for every task.

### Is GPT-5.6 Sol Pro unlimited?

No precise operational plan should call it unlimited. Official plans have usage allowances, model-specific limits, and abuse guardrails. Availability differs across Pro, Business, Enterprise, and individual plan tiers.

### Why not upload the whole private repository?

The external conversation needs only the minimum context for its assignment. A complete repository may contain environment files, internal URLs, historical data, or browser state. Extra data expands exposure without guaranteeing a better result.

### Are three conversations always faster than one?

No. Parallelism works for independent tasks without shared write points. Nearly 20 exchanges can also increase waiting, integration, and retry costs.

### Can the verifier push directly to main after tests pass?

Only when the user explicitly authorizes that action for the current task. Commit, push, pull request, deployment, and database migration require separate authority.

## Authority Sources

- [GPT-5.6 product announcement](https://openai.com/index/gpt-5-6/).
- [GPT-5.6 in ChatGPT documentation](https://help.openai.com/en/articles/20001354-gpt-5-6-in-chatgpt).
- [ChatGPT Pro plan documentation](https://help.openai.com/en/articles/9793128-about-chatgpt-pro).
- [Built-in browser documentation](https://help.openai.com/en/articles/20001277-using-the-built-in-browser-in-the-chatgpt-desktop-app).
- [ChatGPT Work and Codex overview](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex).
- [Codex product page](https://openai.com/codex/).

## Author Insight

I would not evaluate this design by asking which agent is strongest. The better question is which role has the authority to reject unproven code. If Codex merely relays messages without a clean worktree, mandatory gates, and a publication boundary, two models only run the same mistake faster. The workflow becomes governable when the verifier controls source, tests, evidence, and permissions.