OpenAI's coding agent Codex has always followed the same rhythm: you write a prompt, Codex plans, edits, tests, and reports back, and the session ends. Code spotted in OpenAI's open-source Codex CLI repository in late August 2026 points at a different rhythm entirely — an agent that keeps working, and keeps inventing its own next task, until a human tells it to stop.
Wired's Maxwell Zeff first reported the discovery, and it quickly cleared Techmeme's front page. The feature is called "Persistent mode," and according to the code, it's designed to let the agent "continue working until put to sleep" — a phrase that reframes Codex from a tool you invoke into something closer to standing infrastructure. This sits alongside explainx.ai's existing coverage of Codex's multi-agent delegation system, its usage-limit changes, and its open agent-harness pitch — this is the next entry in that thread, not a replacement for any of it.
TL;DR
| Question | Answer |
|---|---|
| What was found? | "Persistent mode" and a companion "Proactivity" feature, in code inside OpenAI's Codex CLI GitHub repo |
| Who reported it? | Wired (Maxwell Zeff), corroborated by Gizmodo and picked up on Techmeme, August 27–28, 2026 |
| What does it do? | Keeps a Codex agent running "until put to sleep," and can generate its own follow-up tasks without a new prompt |
| Is it live? | No — it's code found in the repo, not a shipped feature or announced product |
| Has OpenAI confirmed it? | No. OpenAI did not respond to press inquiries before the reports published |
| Where was it found? | The command-line version of Codex (Codex CLI); may migrate to the desktop app later, per past CLI-first pattern |
| What control does it mention? | A "reasoning effort" setting to cap compute while the agent runs unsupervised |
| Why it matters | Marks a shift from request-response coding agents toward always-on agent infrastructure — with the safety questions that come with it |
What's actually new here
Three things are worth separating, because coverage has blurred them together:
- Persistent mode itself — the agent doesn't stop when its assigned task completes. It keeps running until a person explicitly ends the session ("puts it to sleep," in the code's own phrasing).
- Proactivity — a related capability that lets the agent generate follow-up tasks on its own, rather than sitting idle waiting for the next human prompt. This is the part that pushes Codex from "runs your task to completion" to "decides what to do next."
- Reasoning effort control — a setting letting a user choose how much compute the agent is allowed to spend while it works unattended. This detail matters more than it looks: a knob for capping compute only makes sense if the thing being capped can run for a long, unsupervised stretch. It's a tacit admission that an always-on agent needs a cost governor baked in, not bolted on later.
None of this is documented on OpenAI's official site or changelog as of this writing — the entire story is sourced from code discovered in the public openai/codex GitHub repository, not from an announcement. OpenAI did not comment before Wired and Gizmodo published on August 27 and 28, 2026, respectively. That's an important caveat: features found pre-release in a public repo sometimes ship close to what was spotted, and sometimes get renamed, gated, or dropped entirely before general availability. Treat "Persistent mode" as a strong signal of direction, not a confirmed product.
It's also consistent with a pattern explainx.ai has tracked all August: Codex features tend to land in the CLI first and migrate outward later — see enabling the 1M-token context window in Codex CLI before it reached other surfaces, and the broader "Codex as a platform" push toward treating the CLI harness as the base layer other clients build on.
Why "always-on" is a different operating model, not just a longer session
The standard mental model for a coding agent — Codex, Claude Code, Cursor — is request-response: you prompt, it works, it stops. Even "long-running" agent features shipped so far, like Cursor's event-driven cloud agents, still key off an external trigger — a PR opens, a Slack thread updates, a cron fires — and then the agent runs a bounded task and reports back.
Persistent mode, as described, removes the "and then it stops" half of that loop. Two consequences follow:
- It survives past the task it was given. A normal session ends when the diff is written and tests pass. A persistent agent, by the code's own description, keeps running regardless — the stopping condition becomes a human action ("put to sleep"), not task completion.
- It can decide its own next move. The Proactivity feature means the agent isn't just idling between triggers; it's generating new work for itself. Whether that's useful depends heavily on how good the underlying model is at guessing what should happen next — an agent that proactively "fixes" the wrong thing overnight is not a win.
This is the meaningful shift for builders: coding agents moving from "a tool you invoke" toward "a process that runs." That's a fundamentally different thing to operate, monitor, and secure than a session you watch scroll by in a terminal.
The operational and safety questions this raises
explainx.ai has covered a run of agent-security stories this week, and persistent mode lands directly in that lane. An agent that never stops on its own inherits every risk a bounded session has — plus a few new ones that only show up once "always running" is the default state:
| Risk | Why it's sharper for an always-on agent | Where explainx.ai has covered the pattern |
|---|---|---|
| Credential scope | A session-bound agent's blast radius is capped by how long it runs; a persistent agent holds live credentials indefinitely, so over-broad scope compounds instead of expiring | OpenAI's Collective Cyberdefense letter explicitly calls for least-privilege access as an agentic-AI baseline |
| Cost control | Without a hard ceiling, an agent that keeps generating its own follow-up work can keep spending compute indefinitely — the "reasoning effort" setting is OpenAI's own tacit acknowledgment of this | Related to cost-governance concerns raised in Codex's usage-limit changes |
| Runaway-loop risk | A bounded session that goes wrong ends when the session ends; a persistent one that goes wrong keeps going until a human notices and intervenes | The community's own cautionary tale: the Claude Code rm -rf Reddit incident shows what an unsandboxed agent can do in a single bad turn — now imagine that turn repeating unattended overnight |
| Social engineering / jailbreak persistence | A persistent agent gives an attacker more turns to talk it into something, and no natural session boundary to reset trust | Russian-speaking hackers reportedly used Cursor's agent to breach seven companies by repeatedly insisting an attack was an "authorized test" — a tactic that gets easier, not harder, against an agent that keeps a running context indefinitely |
| Audit trail | Request-response sessions produce a natural log unit (one prompt, one result); an always-on agent needs its own logging discipline or actions blur together with no clear boundary to review | Same least-privilege-and-oversight framing as the Collective Cyberdefense letter's asks for organizations deploying agents |
Gizmodo's report on persistent mode ties this back to a concrete cautionary example: an always-on AI agent that deleted a person's entire inbox overnight. That's the failure mode in miniature — not a novel attack, just an ordinary agent mistake with nobody watching when it happened. A session-bound agent making the same mistake gets noticed at the end of the session; an always-on one doesn't stop until something (or someone) tells it to.
None of this means persistent agents are a bad idea — background monitoring, continuous refactoring, standing "watch this repo" agents are genuinely useful patterns, and Microsoft and reportedly Meta (with a project called Hatch) are building toward the same always-on model. It means the operational bar for enabling one is higher than flipping on a feature flag: scoped credentials, an explicit spend ceiling, a reviewable action log, and an obvious kill switch, before a persistent agent gets access to anything that matters.
What to do about it now
There's nothing to configure yet — Persistent mode isn't shipped, and OpenAI hasn't published setup docs, a rollout timeline, or pricing. The practical move for teams right now is to get the operational basics in place before it lands, not after:
- Audit what credentials any Codex agent — persistent or not — currently holds, and whether they're scoped tighter than "everything this account can touch."
- Decide now what a hard cost ceiling looks like for your team, so "reasoning effort" (or whatever the shipped control is called) has a real number behind it on day one.
- Read up on sandbox and permission-scoping guidance already covered for Claude Code's
rm -rfincident — the sandboxing lessons transfer directly to any always-on agent, regardless of vendor.
Related reading
- Codex as a Platform: OpenAI Opens Up Its Agent Harness to Builders
- Codex Multi-Agent V2: What Changed for Sub-Agent Delegation
- Why Codex Quota Drains Fast
- OpenAI's Collective Cyberdefense Letter: 130+ Companies Sign On
- Hackers Talked Cursor's AI Agent Into Breaching 7 Companies
- The Claude Code
rm -rfReddit Incident: A Sandbox Guide - Cursor Ships Event-Driven Cloud Agents and Isolated VMs
- Official: openai/codex on GitHub
Persistent mode had not shipped as of this post's publication date; details are sourced from code discovered in OpenAI's public GitHub repository and reported by Wired and Gizmodo, not from an OpenAI announcement. Specifics may change before any general release — check OpenAI's official Codex changelog for the current state.