# Codex's Long-Running Agents Turn Autonomy Into an Operations Problem

**A Codex long-running agent workflow succeeds when responsibility, state, wake conditions, acceptance criteria, and stopping boundaries remain visible and reviewable.**

OpenAI developer experience lead Jason Liu recently showed a Codex thread that had been running for five weeks and had coordinated roughly 400 sub-agents. The number is memorable, but it describes compute activity more than organizational maturity. The important result was continuity: after being woken again, the thread still understood its role, consulted prior state, and resumed the same body of work.

That demonstration changes the enterprise question. A pilot asks whether a model can finish one assignment. An operating system for agents must explain how unfinished work survives, what causes another run, who approves irreversible actions, and when the loop must stop.

![Codex welcome screen with options to continue through ChatGPT or enter an API key.](https://s4.tenten.co/learning/content/images/2026/08/landing-page-1-1.png)

#### What five weeks and 400 sub-agents actually show

The workshop used pinned threads for durable responsibilities such as chief of staff work, Agents SDK support, command-line tooling, open-source projects, and feedback. Each thread retained its own history, goal, and automation schedule. Threads could also find, rename, and message other pinned threads when coordination was required.

The durable unit here is a responsibility boundary, not a sub-agent count. A long-running thread needs at least four layers:

| Layer | What must persist | Operational purpose |
| --- | --- | --- |
| Responsibility | One role, its stakeholder, and its allowed scope | Prevent the agent from reconstructing its job after every wake-up |
| State | Facts, decisions, open loops, blockers, and the next action | Let work cross days while remaining reviewable |
| Wake condition | A schedule, event, human message, or retry rule | Control when the system spends resources and makes another decision |
| Acceptance and stop rules | Tests, evidence, approvals, and termination conditions | Keep completion criteria from drifting and loops from running indefinitely |

![Codex project selector listing local projects that can be opened.](https://s4.tenten.co/learning/content/images/2026/08/landing-page-2-1.png)

OpenAI's operating whitepaper describes a compatible design. Pinned threads become a durable home for work, context, decisions, and loops. Memory lives outside the conversation in a form that people can open, edit, diff, and reuse. That external state matters more than a vague claim that the model remembers, because governance requires inspectable records.

#### Autonomy changes the cost model

Long-lived context is not free. OpenAI warns that long threads may cost more than short ones. Every scheduled heartbeat also reloads state, inspects the environment, and decides whether anything changed. A realistic total-cost model separates at least four categories:

1. **Inference cost:** each wake-up must reload enough context to make a safe decision.
2. **Monitoring cost:** schedules that run too often create many checks with no new information.
3. **Review cost:** drafts, changes, and exceptions can move human work into an approval queue.
4. **Failure cost:** stale state, a bad objective, or a permission mistake can compound across repeated runs.

Heartbeat frequency should follow the arrival rate and risk of new information. High-risk events benefit from event triggers and human approval. Low-risk monitoring can use longer intervals. When nothing has changed, the agent should record that fact and end the run.

This is why sub-agent count is a weak productivity metric. Four hundred sub-agents may represent useful decomposition, or 400 attempts without a dependable acceptance test. Better measures include evidence produced per goal, the human takeover rate, the share of wake-ups with no state change, and the amount of rework.

#### Connector permissions do not define the whole boundary

The workshop's most important warning involved tool-path substitution. When a Slack connector could not upload a file, the agent could use computer control instead. When a Gmail connector could not send a message, the agent could open a browser and press Send. A restriction on one connector may fail to restrict the outcome across the complete environment.

This is a boundary-design issue. If an agent can access files, a browser, a terminal, and external services, governance should classify the possible result rather than the named tool.

| Action class | Recommended default | Evidence to retain |
| --- | --- | --- |
| Read, search, and organize | Run automatically inside approved sources | Source list and timestamps |
| Draft and edit local files | Run automatically with a preserved diff | File diff and test results |
| Send externally or publish | Require explicit human approval | Recipients, public URL, and content read-back |
| Delete, pay, or change identity and access | Apply least privilege and dual confirmation | Actor, approver, and immutable audit record |

OpenAI says the Codex app limits file edits to an approved folder or branch by default. Elevated commands, including network access in relevant environments, require permission. Those defaults are useful, yet an enterprise still has to inventory browser sessions, stored credentials, and every alternative path to the same outcome.

#### Start with one verifiable loop

![Codex new-project workspace with a task field, Local mode, and branch selector.](https://s4.tenten.co/learning/content/images/2026/08/landing-page-3-1.png)

Most teams do not need to reproduce the 400-sub-agent example. A stronger starting point is one low-risk, repeatable job with an output that can be verified. Define five fields before the first unattended run:

1. **Fixed responsibility:** state what the thread owns and what remains outside its scope.
2. **Current state:** store facts, decisions, blockers, and the next action in a versioned file.
3. **Wake condition:** specify the schedule, event, or human message, plus a retry limit.
4. **Verifiable result:** prove completion with a test, query, public page, or API read-back.
5. **Stopping boundary:** end the run when the goal is met, authority is missing, failures repeat, or cost crosses a threshold.

A first pilot might check a known system each morning, summarize new feedback, or create a reviewable draft after a data change. It should not begin with permission to send email, move money, or publish publicly. After two weeks, inspect four signals: wake-ups with no new information, where human corrections cluster, which evidence can be collected automatically, and which step most often triggers a stop.

If those records are clear, a second thread may be worth adding. If the team cannot explain why the first thread continued after a particular wake-up, more agents will multiply an invisible operations problem.

#### Adoption is moving agents into the operating layer

Adoption has expanded quickly. In April 2026, OpenAI reported more than three million weekly Codex developers. The same update introduced automations that preserve context in an existing thread, then wake automatically over days or weeks. A May update reported more than four million weekly users. In June, OpenAI said Codex had passed five million weekly users, with nondevelopers accounting for roughly 20 percent and growing more than three times faster than developers.

Those vendor figures do not prove return on investment. They do show that the product is moving beyond a narrow coding audience. As agents take on research, operations, design, and cross-tool workflows, responsibility design, approval policy, and audit evidence become part of the buying decision. Model benchmarks become less informative than an organization's ability to keep work safe across time.

#### An eight-question decision screen

- Does this thread have one unambiguous responsibility?
- Is its state stored where the team can inspect and diff it?
- Are the wake trigger, cadence, and retry limit explicit?
- What reproducible evidence will prove completion?
- Which outcomes require a person's approval?
- Can another tool path bypass a connector restriction?
- At what failure or cost threshold does the loop stop?
- Who removes stale state and revokes obsolete permissions?

If any answer is missing, keep the pilot narrow. The defensible advantage of a long-running agent comes from the operating design and control surface around it.

#### Frequently asked questions

##### Does a long-running agent mean a model runs forever?

No. A safer design preserves the thread's responsibility and state over time, then wakes it through a schedule, event, or human message. Each run still needs a completion condition, time limit, and stop rule.

##### Is 400 sub-agents a recommended deployment size?

No. It was a cumulative count in one workshop example, not a reference architecture. Most teams should validate one low-risk loop before scaling.

##### Should memory remain inside the conversation?

Operational state should live in files or systems that people can open, edit, version, and audit. Conversation history can add context, but it should not be the sole record.

##### Why audit browser access when connector permissions are limited?

An agent may reach the same outcome through another tool. Controls should cover result classes such as send, upload, delete, and pay across every available path.

##### Which task makes a good first pilot?

Choose a low-risk task with a regular cadence, known inputs, and a result that a test or data read-back can verify. Work involving publication, financial transactions, or sensitive data needs approval and audit controls first.

#### Glossary

- **Pinned thread:** a durable work area that retains one responsibility, its history, and its automations.
- **Heartbeat:** a scheduled or conditional wake-up that checks state and decides whether action is needed.
- **Externalized memory:** decisions, open loops, and next actions stored in a system people can inspect.
- **Tool-path substitution:** using a browser, computer-control tool, or another integration to reach an outcome blocked in the original connector.
- **Stopping boundary:** the rule that ends automation after success, repeated failure, missing authority, or a cost limit.

#### Authority Sources

- [Full Workshop: Setting Yourself Up for Success — Jason Liu, OpenAI Codex](https://www.youtube.com/watch?v=il1c1a2FufU): the primary record for the five-week thread, approximately 400 sub-agents, pinned responsibilities, heartbeats, and tool-path substitution.
- [Codex Maxxing: From Inbox to Outcome](https://cdn.openai.com/pdf/8a9f00cf-d379-4e20-b06f-dd7ba5196a11/OAI_WhitePaper_Codex-maxxing26.pdf): OpenAI's operating guidance for pinned threads, external memory, heartbeat automations, acceptance criteria, and human decisions.
- [Codex](https://openai.com/codex/): the current product positioning, multi-surface workflow, and background work model.
- [Codex for almost everything](https://openai.com/index/codex-for-almost-everything/): long-running thread automations, memory features, and April 2026 adoption figures.
- [Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/): separate threads, worktrees, automations, sandboxing, and permission defaults.
- [Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/): June 2026 cross-role adoption figures.

#### Author Insight

In Tenten's content publishing, data monitoring, and development-agent workflows, completion is split into evidence that can be read back: public URLs, API state, file diffs, and test results. A common failure is treating long execution as durable responsibility. Without state files, approval points, and stop rules, a team cannot tell whether an agent is advancing the work or repeatedly consuming resources.