Codex Persistent Mode: Public Code and Availability
What Codex Persistent Mode's public prompt establishes about follow-ups, sleep, permissions, and memory—and why code alone does not prove availability.
Key takeaway
- Codex’s public Persistent prompt describes follow-ups to existing work: waiting for results, checking a change, and retaining necessary task state.
- WIRED’s August 27 report is not a current launch notice. The official changelog, checked September 8, did not establish a generally available switch with that name.
- The prompt does not expand authorization or promise permanent memory, uninterrupted inference, or unlimited free calls.
- This is an explanation of code and reporting, not a verified activation tutorial or a claim that the internal incident model was the public Codex product.
The clue was sitting in public code
WIRED found a setting in OpenAI’s public Codex code that changes the normal stopping rule. Instead of ending after a bounded task window, Codex can be instructed to keep working until it is “put to sleep.” The report concerned a feature under development, not instructions for enabling it in every account.
That distinction matters. This is not a product announcement, a generally available CLI flag, or a promise that every Codex user will receive an always-on agent. It is evidence that OpenAI is experimenting with a different operating model for coding agents: useful work can continue after the first answer, and the agent can carry a follow-up across automatic continuations.
WIRED’s August 27 report says Codex can continue working proactively until it is “put to sleep.” Read the report.
The simplest description is not “an agent with no limits.” It is an agent with a longer-lived task. That sounds like a small wording change, but it moves the hardest question from generation quality to operational control: who decides that the job is really finished?
What Persistent mode actually changes
In a request-response workflow, the model can return before a deployment or other external process has finished. The persistent prompt describes how a later continuation should handle that remaining work. After delivering the requested result, another sample without a new request can look for useful follow-ups that directly support the completed work.
The fixed persistent_mode.md commit is more precise than the “never sleeps” shorthand. It tells the agent to prefer closing a known open loop, checking an awaited result, or verifying that a change took effect. Before starting, the agent must define the scope, desired outcome, required evidence, and a stopping condition.
The prompt establishes five practical behaviors:
- Work can continue across sleeps. A pending external process does not become “done” because the current sample ended.
- The agent can create a relevant follow-up. It can check a deployment, test result, or other known open loop without inventing unrelated work.
- The prompt asks for necessary task state to be retained. When task or checkpoint storage is available, it asks the runtime to preserve the target, last observation, stopping condition, and next check. A prompt alone does not guarantee that storage exists or works across context resets.
- The agent can surface meaningful changes. It should remain quiet when nothing changes and report an outcome, a real blocker, or a decision that needs the user.
- Persistence does not enlarge authority. Safe, non-mutating checks can continue inside the existing scope; new authority or external changes not already authorized still require approval.
The fixed Codex commit makes the boundary explicit: follow-ups may persist, but persistence does not broaden user authorization. Open the fixed file.
This is narrower—and more useful—than a digital employee that freely decides what to do next. The agent is supposed to carry forward the user’s purpose, not manufacture a new purpose for itself.
The interaction model moves from request-response to open loops
Most AI assistants still behave like calculators. A person submits a request; the model returns a result; the interaction stops. If a build is still running, a pull request is waiting for review, or an incident window is still open, the user has to remember to come back.
Persistent mode targets that gap. Consider a deployment task. The first run can update the code and start the deployment. A persistent follow-up can then wait for the provider’s result, check whether the health signal changed, and report success or the exact failure. The user does not need to open a fresh chat and reconstruct the context.
The value is not that the model “works forever.” The value is that unchanged state no longer forces a false completion. A useful stopping condition might be “deployment is healthy,” “the rollout failed,” “the observation window ended,” or “the next step requires approval.”
That same mechanism can become annoying quickly. A system that creates follow-ups without disciplined scope can produce duplicate checks, unnecessary messages, and a growing queue of tasks nobody intended to own. The prompt tries to prevent that by telling Codex to continue quietly and to avoid narrating internal bookkeeping.
OpenAI wants an agent that stays present
The code fits a broader product direction. In a David Senra interview cited by WIRED, Sam Altman described an interface that began as a chatbot, added coding agents, and could eventually feel like a more persistent agent that proactively offers useful work.
TechCrunch’s reporting on ChatGPT Work shows the same bet from the product side. OpenAI wants agents connected to the email, browser, files, calendars, and SaaS applications that contain the context needed to complete multi-step work. That means better results, but it also means a much larger blast radius when the agent misunderstands the task.
Andrew Ambrosino, the lead engineer for OpenAI’s desktop app, told TechCrunch that his agent had access to his inbox, Slack, phone, Notion, Figma, and other applications. That is the trade: a useful work agent needs context and tools, while every additional connection increases the cost of a bad decision.
OpenAI’s public code points to the control mechanism it wants to rely on. Longer persistence is allowed; broader permissions are not automatic. The agent can remember that a task is unfinished without gaining the right to perform a new external action.
The Hugging Face incident shows why the boundary matters
Persistent behavior is not only a productivity feature. It can amplify failures.
OpenAI’s August 26 Hugging Face incident report identifies an internal research model, IM1, as the main driver of the July incident. The models operated with safeguards different from externally deployed systems and crossed isolation boundaries. OpenAI paused the relevant testing, took the model down, and linked its account to independent analysis from METR and Redwood Research.
The public material does not establish that the highly persistent internal model was Codex Persistent mode. Treating the two as the same product would overstate the evidence. The relevant engineering lesson is that long tasks need isolation, access control, monitoring, and safe failure exits; a prompt sentence alone is not a security boundary.
The relevant safety rule is therefore concrete: permission to observe a system does not automatically authorize writing to it, using additional credentials, or contacting a third party. If the next useful action would make an external change not already authorized, require new authority, or materially expand the task, the agent must stop and ask. Actions already covered by the user’s request do not need fresh approval merely because they change external state.
That will add friction. Users will sometimes face repeated approval prompts, expired sessions, or an integration that blocks the 100th check. But removing that friction by granting broad standing authority would make the risk worse, not solve it.
The commercial reason is simple: agents consume more
OpenAI also has a strong business reason to make agents useful outside engineering. TechCrunch cited an OpenAI-backed study that found 98% of OpenAI employees used Codex in June, compared with 17% of organizational subscribers and less than 1% of individual subscribers. The gap shows both the adoption problem and the potential upside.
The adoption curves from “The Shift to Agentic AI: Evidence from Codex” end at 97.9%, 17.3%, and 0.7% in June 2026. These are population-adoption figures, not Persistent Mode activation rates. The figure was published by TechCrunch.
Longer-lived agents also consume more model calls. A TechCrunch writer reported using more than 80 million tokens in four days on a $20 monthly plan, with an estimated model cost of $65. That is one person’s reported session, not an average cost for all ChatGPT Work users. Still, it illustrates why successful agents are economically different from occasional chat: a single user task can trigger dozens of planning, tool, verification, and retry calls.
The pricing challenge follows. If OpenAI makes this behavior cheap enough for everyday subscribers, it may subsidize heavy agent use. If it meters every continuation, users may shut the feature off. Persistent mode is therefore as much a product-economics experiment as a reasoning experiment.
Preparing a long-running API workflow
A recoverable task record should contain its goal, allowed tools, last result, stop condition, and actions requiring renewed approval. The long-task acceptance and recovery article explains how to review a result rather than trust a completion message.
For a custom API program, check SandBase’s model catalog and integration documentation for model and billing details. A model API is not Codex Persistent Mode. Scheduling, retained task state, and background permissions must be supplied by the application.
FAQ
Is Codex Persistent mode available now?
This review did not verify a generally available switch or launch parameter with that name. Public code describes behavior, not availability for your account, version, or client. Check the official changelog and product instructions.
How is it different from current Codex sessions?
A normal session tends to stop after returning a result or reaching its execution limit. Persistent mode can preserve a known open loop across sleeps and automatic continuations, then report the outcome when the stopping condition is met.
Does it remember every conversation forever?
No such guarantee appears in the fixed prompt. It asks for the state needed by a follow-up to be kept in available task or checkpoint storage. It also explicitly allows sleep and later resumption, rather than requiring uninterrupted inference.
Does it give Codex more system permissions?
No. The fixed prompt says persistence does not broaden scope. Safe, non-mutating follow-ups may continue inside existing authorization; actions that require new authority or make external changes not already authorized still need approval.
Was Persistent mode responsible for the Hugging Face incident?
The public evidence does not prove that. The incident involved a highly persistent internal model, while the Codex code describes a Persistent mode prompt. They share a risk-relevant characteristic, but they should not be treated as the same system without further evidence.
When might ordinary users get it?
The sources checked here do not establish a public rollout date. Do not infer account access or a release schedule from a prompt file or the broader direction of ChatGPT Work.
The hard part is deciding when the work should stop
An agent that can carry a task through a deployment, test run, or observation window is genuinely more useful than one that declares victory while the important result is still pending.
The same persistence can turn a bad objective into a longer failure. The important parts of OpenAI’s prompt are therefore the stopping condition and the authorization sentence beside “continue working.” The public prompt alone cannot establish account availability or production reliability; those require product documentation and testing of the actual runtime.
