Coding Agents That Outlive Your Session

Always-on coding agents took a concrete step on August 19, 2026, in two separate vendor changelogs. Cursor’s entry, titled “Cloud Agents and Cursor Harness Improvements,” teaches cloud agents to subscribe to events, hold long-lived goals, and spawn subagents on isolated virtual machines. OpenAI’s entry connects Codex cloud to GitLab, in beta, on every ChatGPT plan.

Neither entry is a model release, and neither comes with a benchmark. What they share is a direction: both vendors are building agents that keep working after the person who started them has moved on. Cursor’s own framing is explicit — the goal is always-on agents that operate “without the need for intervention at each loop.” That phrase is doing a lot of work, because the loop it removes the human from is the one where authorization used to live.

This is not a Cursor how-to — we have already published a hands-on guide to Cursor’s isolated-VM cloud agents for that. This piece covers what each vendor actually shipped, why GitLab landing in Codex cloud matters more than a routine integration, and the operating-model question both entries raise: who reviews an agent that never stops, and how a scheduled agent gets its authority in the first place.

Start with what the primary sources actually say. Cursor’s August 19 changelog entry, at cursor.com/changelog/08-19-26, bundles six cloud-agent and harness changes: event subscriptions, automatic PR follow-through, always-on skills via custom modes, subagents on their own virtual machines, a /goal command for long-lived objectives, and mid-run steering. OpenAI’s entry for the same date, in the ChatGPT & Codex changelog, is shorter: GitLab support in Codex cloud, in beta, on all ChatGPT plans.

One framing note before the details. Some coverage will attach a graduation-style maturity label to the Cursor release. Cursor’s own page carries no such label — its framing is about what the system can now do, not about a release tier. We describe it in Cursor’s terms: cloud agents that “can operate as a system” without per-loop intervention. The Codex entry, by contrast, is explicit about its status: the GitLab integration is a beta, and OpenAI names specific gaps it has not closed yet.

Sequencing matters too. Two days earlier, on August 17, Cursor began rolling out Origin, its own code-hosting product, in early beta. Origin and the August 19 cloud-agent work are separate changelog entries with separate feature sets — one is where code lives, the other is how agents behave — and collapsing them into a single announcement misreads both.

The load-bearing change in Cursor’s entry is subscriptions. Per the changelog, Cursor can now monitor your PRs, watch a Slack thread, or run scheduled tasks: the agent subscribes to an event source and wakes when something happens. Subscriptions are available for cloud agents only, for now. The significance is easy to miss because each piece sounds incremental — but together they change what kind of thing a Cursor agent is. An agent with a subscription does not need a person to prompt its next action. The trigger is a CI failure, a bot comment, a Slack message, or a clock.

The example prompt Cursor gives for PR follow-through is worth quoting because of what it implies: @cursor check back in an hour and keep going until that feedback is in. The human sets a policy once; the agent executes it on its own schedule. Combined with /goal and subscriptions, a Cursor cloud agent can now be configured to pursue an outcome — green CI, merged PR, resolved feedback — across as many wake-ups as it takes. What Cursor has not published is any limit on how many subscribed or scheduled agents a workspace can run concurrently, or what this costs at scale; the changelog and the cloud-agent docs are silent on both, so we keep those dimensions qualitative.

The Codex side is narrower but structurally significant. Per OpenAI’s GitLab integration guide, a connected GitLab project gets a Codex environment where the agent can edit files, commit, and push to merge-request branches. Mentioning @codex review on an MR posts findings as GitLab discussion comments. Automatic reviews can trigger when an MR opens, on every push, or via a smart trigger. Mentions of @codex on issues or MRs start cloud chats seeded with repository context, and — when authorized — Codex can push fix suggestions back to a branch.

The admin surface is deliberate. The integration runs in Codex cloud, and a managed workspace admin can disable the connector entirely. GitLab-triggered activity requires permission to configure the applicable webhook. For GitLab Self-Managed or GitLab Dedicated, a workspace admin must configure the connection, and webhook activity requires GitLab 19.0 or later. Setup runs through service accounts: Codex either creates one or uses an existing account with Developer-level access to the target groups and projects.

Here is the observation that makes a two-sentence changelog entry a story — and it is our framing, built on what Codex’s own documentation does and does not contain. Before August 19, Codex cloud connected to exactly one source-control provider: GitHub. The Codex cloud docs now carry onboarding copy reading “Connect GitHub or GitLab (Beta) when prompted,” and no other provider — not Bitbucket, not Azure DevOps — appears anywhere in Codex’s cloud or third-party integration docs as of this writing. By that evidence, GitLab is Codex’s first cloud SCM integration beyond GitHub since the product launched.

That matters for a structural reason. As long as Codex cloud spoke only GitHub, every team on GitLab — a large share of enterprise and self-hosted source control — was outside its addressable surface entirely, whatever the model quality. The beta converts Codex cloud from a GitHub feature into a multi-SCM product, and the Self-Managed and Dedicated support signals who it is aimed at: organizations that run their own source control precisely because they have compliance or sovereignty constraints — the same organizations most likely to have opinions about an AI agent holding Developer-level access.

It also completes a week of steady Codex platform motion: the day before, Codex CLI 0.148.0 added session forking and Amazon Bedrock as a built-in provider — covered in our August 18 operator-changes breakdown — and the GitLab beta followed twenty-four hours later on the cloud side. The CLI and the cloud are advancing on parallel tracks, and the cloud track is the one that runs while you are away.

Read together, the two entries mark a shift in the unit of agentic work. The first generation of coding agents was synchronous: a person opens a session, issues a prompt, watches the run, and the work dies with the tab. The second generation went asynchronous — kick off a background run, come back for the result — a trade-off we mapped in our guide to choosing between synchronous and background agent workflows. What shipped on August 19 is a third mode: the agent as standing infrastructure. A subscribed Cursor agent and a Codex automatic MR review share a defining property — their next action is not preceded by a human prompt. A person configured a policy once; the event stream does the invoking from then on.

Cursor’s cloud-agent docs state the engineering logic for why these agents get full environments rather than sandboxed subsets — and the same sentence explains why the governance question is now unavoidable.

Closing the loop is exactly the capability that used to define where the human sat. When the agent could not run tests, a person had to; the review point was built into the workflow’s physics. Give the agent cloned repos, dependencies, secrets, startup commands, and network access — which is what Cursor’s cloud agents get, with the platform managing VM provisioning, isolation, snapshots, and capacity — and the human checkpoint no longer happens by default. It has to be designed. That is not an argument against the capability; an agent that cannot verify its own work pushes the verification cost onto you. It is an argument that the interesting decisions have moved out of the prompt and into the configuration.

Neither vendor prescribes a review workflow — both ship control surfaces and leave the policy to the team. That is the right division of labor, but it means the accountability design is now your job. The matrix below maps the main controls each vendor documents for these releases against the question each one answers. Two patterns stand out. First, both vendors put the authorization gate at the organizational level: a Cursor account admin links source control and grants agents read-write access to repos and their dependencies; a Codex workspace admin enables the GitLab connector, owns the service account, and can shut the whole thing off. Second, neither vendor automates the merge decision — the agent can fix CI and answer review comments, but what merges, and when, remains wherever your branch protection puts it.

Codex’s three automatic-review triggers are worth pausing on, because they are a rare concrete example of an accountability gradient expressed as configuration. Reviewing on every push is the strictest posture — nothing lands unexamined, at the cost of noise. Reviewing on MR open checks intent once and trusts iteration. The smart trigger delegates even the when-to-review decision to the system. Each step trades human attention for throughput, and the right setting is a function of the repo’s blast radius, not of taste. If your team has not written down who owns an agent’s output — who is the accountable human for a PR the agent opened at 3am from a scheduled subscription — our agent governance framework is the place to start; the access-policy questions it walks through map one-to-one onto the admin gates in the table above.

The practical question is not whether to adopt always-on agents — for most teams it is which subset to adopt first, and with what guardrails. Four postures cover the realistic starting points.

One projection we will stand behind: the vendors’ next moves make the governance gap more visible, not less. Cursor is explicit that subscriptions are cloud-only “for now,” and OpenAI’s beta label plus its named parity gaps signal an intent to close them — which likely means MR creation and richer repository controls eventually reaching GitLab. Every one of those steps widens what an agent can do without a person in the loop, and none of them will ship with your team’s review policy attached. Teams that treat agent authorization as an organizational design problem now — the way they once treated CI permissions or deploy keys — will absorb each new capability as configuration. Teams that treat it as a per-developer preference will discover their actual policy by incident. If you want a structured way through that design work, our AI transformation engagements build exactly these operating models — and for the wider tooling landscape these two vendors sit inside, our coding-agent comparison maps the field.