Written for engineering leaders evaluating the workflow. Researched August 2026. Every capability named here is documented, and sources are listed at the end.
OpenAI shipped the Codex desktop app in February 2026 and described it as a command center for agents rather than an editor, built for running work in parallel and collaborating with agents over long-running tasks. [1] That framing is the shift worth planning around. The question for an engineering organisation is no longer how well an agent writes a function. It is whether the work survives between sessions: whether decisions get written down, whether routine checks happen without anyone asking, and whether a run lasting hours can be reviewed instead of babysat.
What follows is the adoption order that the documentation and the practitioners both converge on. Where the popular version of this advice misdescribes how a feature works, that is flagged rather than repeated.
One internal experiment run on GPT-5.3-Codex at Extra High reasoning ran for 25 hours, consumed 13M tokens, and produced about 30,000 lines of code, verified at each milestone. The author calls it an experiment, not a production rollout. [7]
Stop managing, start correcting
The habit that separates people who get value from agents from people who get demos is unglamorous: they say precisely what is wrong and make the correction permanent. OpenAI's own customization guidance treats this as a loop. When the agent makes an incorrect assumption about your codebase, you correct the output and add the durable rule to guidance so the mistake is less likely next time. [2]
The documented triggers for editing that file are worth adopting as team rules. Add a rule when the agent repeats a mistake. Add routing guidance when it finds the right files but reads too many documents. Codify any review comment you have now left twice. [2] Guidance loads from two places, a global user file and a repo file, so personal habits and team conventions can stay separate.
Pair the file with enforcement. The docs are direct about this: pre-commit hooks, linters and type checkers catch the same class of error before a human sees it, so the rule stops depending on the agent remembering. [2]
Give the work somewhere to live
Long threads accumulate understanding, and that understanding is trapped unless something writes it to disk. The pattern practitioners describe is a single repository outside any one project, holding the rolling context around your work: people, projects, decisions, open loops, daily notes. Jason Liu calls this a vault, and the important part is not the name. It is that the agent has a durable place to update what it learned. [4]
Keeping the vault in Git buys the part that matters for a team: the diff becomes the review surface for memory. When the agent decides something is worth remembering, you read what it wrote and either accept it or correct it, exactly as you would any other change. [4]
Threads sit on top of that. Rather than hundreds of disposable chats, pin one long-running thread per workstream and return to it. The app supports jumping straight to pinned threads with Command-1 through Command-9, and compaction keeps a months-old thread usable by compressing its history instead of discarding the work context. [1]
Codex also has a first-party memory feature, and it is worth being precise about its role. Local memories are off by default, are generated in the background from eligible past chats, and are stored as files under your Codex home directory. The documentation is explicit that they are generated state for recall, not the system of record. Rules that must always apply belong in checked-in guidance. [3]
Put the recurring work on a schedule
Automations are how a thread stops waiting for you. An automation combines instructions with optional skills and runs on a schedule you define. When it finishes, the result lands in a review queue so you can pick the work back up. [1] OpenAI reports using them internally for daily issue triage, finding stale pull requests, identifying active feature flags, drafting follow-ups, and monitoring experiment results. [1]
The recommended way to create one is to get the behaviour right in conversation first, then convert that thread into a schedule, because a good automation is specific, repeatable and easy to review. [9] Some automations return to the same conversation and continue from the context already there, which makes them more like recurring staff work than a one-off script.
Two constraints belong in any evaluation. First, refine the schedule with the same corrective habit as everything else: ask it to include direct links, to pre-draft responses, to close the loop by replying in the channel once a task is done. Second, know where it runs. Automations execute in the background on your machine at the scheduled time. Cloud triggers were described as coming, not shipped, at app launch. [1]
Build a skill library, then package it
A skill is a folder: a required SKILL.md holding metadata and instructions, plus optional scripts/, references/ and assets/. [2] Skills load by progressive disclosure: Codex starts with names and descriptions, loads the full file only when a skill is chosen, and reads references or runs scripts only when they are needed. That is the right shape for delegation. You are not pasting a giant prompt into every task. You are teaching a reusable capability.
Placement decides scope. Skills in your user directory follow you across every repo; skills checked into a project's .agents/skills belong to the team. [2] Once a related set works, the documented distribution step is packaging: a plugin bundles skills, MCP servers, connectors and agent definitions into one installable unit. [2]
The scale is not hypothetical. OpenAI says it has built hundreds of skills internally, covering work its teams found hard to delegate consistently, from running evals to drafting documentation and reporting on growth experiments. [1]
Audit the library instead of letting it grow
Every configuration layer that accumulates without review eventually costs more than it saves. Bloated guidance files and overlapping skills are the failure mode to plan for, and the documented remedy is to point the same machinery at itself: use an automation to run a recurring check that looks for stale rules, duplicated instructions, missing validation commands and skills that should be consolidated.
The stronger version of the loop, and the one I could not fully verify, is asking Codex to read back your own session history to find which skills went unused and which corrections you kept repeating, then folding those corrections into the skill so you stop asking. The mechanism is sound and the intent matches the product direction. Treat it as a pattern to test, not as a guaranteed turnkey feature.
Know which surface can see what
Three different surfaces let an agent touch things outside the repo, and choosing wrongly is the most common source of disappointment. The distinction is what each one can see.
| Surface |
Use it for |
Important constraint |
| Built-in browser |
Local web surfaces you want to inspect and annotate |
It runs on its own profile and does not share your existing tabs or browser session, so you sign in inside it when a task needs an account. [5] |
| Chrome extension |
Tasks that need your real Chrome profile, signed-in state, or several authenticated tabs |
This is the right surface when the agent needs what your normal browser can already see. [5] |
| Computer use |
Work that only exists as a GUI |
On macOS it needs Screen Recording and Accessibility permissions; on Windows it runs on the active desktop and takes over the pointer and keyboard while it works. [6] |
This is where the multi-tab research pattern earns its place. Instead of asking for a summary, ask the agent to do the comparison and leave each candidate open in its own tab for you to judge when you get back. It works because the browser surfaces can hold several authenticated sessions in parallel while the agent does the mechanical work.
Two guardrails the docs state plainly. Prefer a structured integration, a plugin or MCP server, whenever one exists, and reach for computer use only when the agent genuinely needs to operate the interface. [6] Treat page content as untrusted: allowing a site does not make its instructions trustworthy.
Long runs need a target, a plan, a runbook and a log
The 25-hour run quoted above was not the product of one clever prompt. Its author attributes it to durable project memory: the spec, plan, constraints and status written into Markdown files the agent revisited throughout, which is what kept a stable definition of finished and prevented drift. [7] Four files are enough to make the pattern concrete.
| File |
Purpose |
prompt.md |
Freezes the target. Goals and non-goals, hard constraints, deliverables, and a "done when" section with the checks and demo flow that prove it. |
plans.md |
Milestones small enough to finish in one loop, each with acceptance criteria and validation commands, plus a stop-and-fix rule and decision notes so the agent stops oscillating. |
implement.md |
The runbook. Follow the plan milestone by milestone, validate after each one, fix failures immediately, keep diffs scoped, update the docs as you go. |
documentation.md |
Shared memory and audit log. Current milestone status, decisions and why, how to run and demo, known issues. This is what lets you step away for hours and still understand what happened. |
Verification is the load-bearing part, not the ambition. The run ran lint, typecheck, tests and build at every milestone and repaired failures before continuing. [7] The same principle shows up in the strongest practitioner framing of goals: a weak goal restates a plan, a strong goal names an oracle the agent can keep testing against. Porting a Python library to Rust becomes tractable as a goal because the original test suite decides when it is done. As Liu puts it, "Ambition without verification is just a wish." [4]
Two features support the long run itself. Plan mode, toggled with /plan, breaks a large task into a reviewable sequence and asks clarifying questions before anything changes. [7] Subagents spawn specialised agents in parallel and collect their results, which suits codebase exploration and multi-step plans. In local Codex you generally have to ask for delegation explicitly, or request it from your guidance files. [8] Worktrees keep parallel runs from colliding on the same repo. [1]
Four things the popular version gets wrong
- The in-app browser does not inherit your logins. It keeps a separate profile and does not automatically share your tabs or session. Use the Chrome extension when the task depends on signed-in state. [5]
- Scheduled automations are not free-standing cloud jobs. They run in the background on your machine at the scheduled time. Cloud triggers were described as coming, not shipped, at app launch. [1]
- Memories are not the system of record. Off by default, generated in the background, and documented as a recall layer. Rules that must always apply go in checked-in guidance. [3]
- The 25-hour run is an anecdote, not a benchmark. One author, one repo, one model setting, explicitly labelled an experiment. Use it to size ambition, not to forecast throughput. [7]
Start today
In adoption order. The first three take an afternoon and are what make the rest worth doing.
- Write the repo
AGENTS.md: build and test commands, review expectations, the two conventions people explain most often to new joiners.
- Create the vault as a Git repo with the standing instruction to write things down, and read the first few diffs it produces.
- Pin one thread per workstream. Stop opening new chats for related work.
- Get one read-only automation right in conversation, then schedule it. Start with reporting, where a bad run costs nothing.
- Turn the next repeated correction into a skill, and check it into
.agents/skills if the team needs it too.
- Decide the surface policy before anyone needs it: which browser for what, and which apps computer use may touch without asking.
- Pick one long task that already has a test suite, and run it with the four-file stack. The suite is the oracle; without one, wait.
None of this is a productivity trick. It is the difference between an agent that answers and a system that keeps working on your behalf, and the thing that separates them is how much of your judgement you were willing to write down.
Sources
- OpenAI, "Introducing the Codex app", 2 February 2026, updated 4 March 2026.
- OpenAI Codex documentation, "Customization", accessed 3 August 2026.
- OpenAI Codex documentation, "Memories", accessed 3 August 2026.
- Jason Liu, "Codex-maxxing", 10 May 2026. Practitioner account, not vendor documentation.
- OpenAI Codex documentation, "Browser", accessed 3 August 2026.
- OpenAI Codex documentation, "Computer Use", accessed 3 August 2026.
- Derrick Choi, "Run long horizon tasks with Codex", OpenAI Developers, 23 February 2026.
- OpenAI Codex documentation, "Subagents", accessed 3 August 2026.
- OpenAI Academy, "Scheduled tasks", accessed 3 August 2026.
Sources checked 3 August 2026.
