Opens in a new tab
News

A fresh Codex Cloud task and a resumed one can have different tools

In brief

Prepare the toolchain once, then let each task keep its own work. That useful separation also explains why republishing an environment does not update an unfinished task.

4 min read

Is this the right starting point?
Before you read
Basic coding-task, repository and dependency/test workflow concepts.
What you will take away
Distinguish a published starting environment from an existing task’s retained workspace and verify which tools tested a patch.
Sources
Screenprint illustration of blue-circle and ochre-diamond prints beside matching blocks; red brush marks cross the blue-circle sheet.
On this page3 sections

The dependency fix is small. Installing the compiler and packages to test it is not. A reusable Codex Cloud environment lets the team do that preparation once, so the next task can begin closer to the work it came to do. Each task then gets its own workspace, rather than everyone editing the same prepared folder.

OpenAI described the feature in the September 29 ChatGPT Business notes and release-week documentation. With workspace cloud access, tasks can start or continue from desktop, web or mobile and keep running while a laptop sleeps. For the person maintaining the project, one distinction matters immediately: starting a task and reopening one do not restore the same kind of saved state.

The shared starting point stops being shared work

Publishing captures the prepared files and tools for new tasks. Each new task gets a separate workspace to change. Reopening an existing task instead brings back its own saved files, including uncommitted edits and installed tools, while that state remains available. The environment documentation describes these as separate paths.

Imagine two maintainers beginning with the same project setup. One updates a dependency; the other investigates a failing test. Soon their files differ, as they should. A better prepared toolchain published tomorrow should help the next task without replacing either maintainer’s unfinished patch today.

Published environment version one starts task A. After republishing the environment as version two, new task B uses version two while task A keeps its existing files.
The version labels illustrate the distinction: republishing changes the starting setup for a new task, while an existing task keeps its own working state.

Save and Publish have different jobs too. Saving stores the configuration; publishing captures the prepared filesystem. To update a published setup, the documented sequence is to edit it, prepare and test the change, save, then choose Republish. New tasks pick up that prepared update. Existing ones continue their own work.

Two test results, two versions of the runner

Suppose the original setup had an outdated test runner. The team fixes the preparation and republishes it. A fresh task now has the corrected runner. A resumed task may still have the earlier one alongside the patch it was working on. Nothing has necessarily gone wrong with the separation, but the two tests no longer begin on equal terms.

When their results disagree, compare the runner versions and the exact commands before blaming a regression in the code. Finding different tools gives you a useful lead, not proof that either result is right.

There is also a limit to how long continuation can be relied on. OpenAI documents recovery of saved virtual-machine state by default for up to seven days after the last turn starts or the task is resumed. Commit important work or preserve the output independently. The saved workspace is convenient for picking up a thread; source control still needs to hold the changes that matter.

Hand over the patch with the test that ran

For a dependency update, a useful handoff includes the lockfile changes, test command, exit status and environment that ran it. Those details let the reviewer connect this patch to this test with these tools. A completed-task indicator cannot make that connection on its own.

Before sharing the prepared setup, look through its files as well. Direct environment variables are passed to programs. Network secrets work differently: programs receive placeholders, and a proxy substitutes the real values for matching requests to allowed HTTPS destinations. That mechanism does not remove a credential someone already wrote into a file. Publishing preparation can carry that file forward too.

For a hypothetical maintenance trial with familiar tests, start two tasks, change files in one, and check that the other remains separate. After republishing a toolchain change, compare a new task with a resumed one, then put the patch through the usual release checks. These are proposed checks, not a product test performed for this article.

The payoff is a prepared starting point without a shared pile of unfinished edits. When a reviewer asks which runner checked the patch, the answer should travel with the patch. Then the team can save the repeated setup work without guessing what happened afterward.

Sources & context

Sources linked in this article. Read alongside the author’s analysis; a citation does not independently verify a publisher’s claims.

Report an error or outdated detail

More on OpenAI

All OpenAI coverage

Keep reading

Where to go next