Codex Cloud uses a separate workspace for each task. If you need to keep a change, reopen the original task, verify its diff, and commit important work to version control before switching tasks. A new task does not automatically recover another task’s uncommitted files, and a saved VM recovery window is not a promise of permanent storage. OpenAI’s Codex Cloud documentation describes the task and recovery boundaries.
Last updated November 8, 2026. Task, workspace, and VM-state statements were checked against the OpenAI Codex Cloud help document; repository guidance was checked against the linked GitHub documentation.
This guide is for developers using Codex Cloud on a trip who need to locate changes after a task ends or a connection drops.
It’s also for people using a phone, iPad, or lightweight laptop who want a repeatable save routine before leaving their desk.
If you’re delivering an iOS project, it will help you separate cloud code work from later checks that require a Mac toolchain.
Identify which layer has the missing change
A Codex Cloud task involves separate things that can look like one continuous work session: the task conversation, the task’s workspace and files, the saved virtual machine state, and the Git repository. Treat each as a different place to verify work.
A completed-looking response in the conversation is evidence that the task produced a result. It is not evidence by itself that the result was committed to the repository, pushed to GitHub, or copied into another task’s workspace. Open the original task and inspect its changes before starting work elsewhere.
Use this sequence when a project appears unchanged:
- Conversation: Find the original task and read its final status and summary. Don’t rely on a notification or a remembered response.
- Workspace: Open that task’s diff and check whether the expected files appear. A task’s own workspace is the first place to look for uncommitted work.
- Repository: Check the branch and commit history. A file visible in a task may still be absent from the repository’s recorded history.
- Remote repository: If you expected a push, verify the remote branch separately. A local commit and a successful push are different states.
If a task result is visible but its files are not, don’t immediately repeat the task in a new workspace. Repeating it can create a second set of changes without resolving the first one.
Reopen the original task before starting another
A new Codex Cloud task is not a continuation of the previous task’s workspace. OpenAI documents that tasks use independent workspaces; starting a new task does not automatically bring forward another task’s uncommitted changes. To continue the same work, return to the original task and use its continuation path where available. OpenAI’s task guidance is the source of truth for the current behavior.
When you return to a task, check these items before asking for more code changes:
- Confirm that you opened the original task, not a similarly named new one.
- Read its current status and any completion or error details.
- Inspect the changed-file list and diff. Look for the files related to the work you expect.
- Review test output or run the relevant checks again if the environment allows it.
- If the change needs to move into a different task, preserve it deliberately through a commit or an intentional file transfer. Then verify that the destination workspace contains it.
This is especially useful when you’ve been working from a phone or iPad between travel connections. A task title or conversation may be easy to find on a small screen, while the specific workspace and branch are not. Before continuing, confirm that the task you opened contains the code you intend to edit.
Quick rule: continue the original task to inspect its workspace; use a new task only when you intend to start with a separate workspace or have explicitly transferred the required code.
Treat recovery as a limited window, not a backup
If you’ve been away from a task, first open that original task and see whether its status and files are still accessible. Codex Cloud documentation describes a recovery window for saved virtual machine state. The window is limited and applies to saved VM state; it does not mean the conversation history and every file are guaranteed to remain available for an unlimited time. Check the current recovery details in OpenAI’s documentation before relying on them.
Keep these distinctions clear:
- Saved VM state concerns whether an environment can be resumed under the documented conditions.
- Task conversation records the interaction, but a visible conversation is not proof that files remain accessible.
- Git history records committed changes. It is the more dependable way to review work across task changes and environment interruptions.
- An uncommitted diff remains dependent on access to the workspace where it exists. Don’t treat the recovery window as your only copy.
If you cannot see the expected files, separate the failure into three checks. First, make sure the original task is open and inspect its status. Second, check whether the task’s files and diff are available. Third, check whether the repository and account have the access needed to view or push the code. If the task itself is unavailable, don’t infer that the conversation can reconstruct its VM state.
A task’s saved environment and its source-control record serve different purposes. Use the task to resume work when it is available; use commits to preserve work you need to review later.
Review and commit before you leave the session
Before you close a laptop, switch tasks, or leave an unreliable connection, establish what has actually been saved. Reviewing the diff catches accidental edits. Running the project’s checks helps reveal incomplete work. Committing gives you a source-control record that is easier to inspect and carry forward than an uncommitted workspace change.
Use this handoff routine:
- Review the diff. Confirm each changed file belongs to the task. Look for unfinished edits, generated files, secrets, or unrelated changes.
- Run relevant tests. Use the checks appropriate to the project. If a test cannot run in the current environment, note that limitation instead of treating the task as verified.
- Check the branch. Confirm that you’re working on the intended branch and that the changes are not mixed with unrelated work.
- Commit the intended changes. Create a clear commit only after reviewing what it contains. GitHub’s guide to adding a file to a repository explains the repository workflow and why a file needs to be committed to enter the project history.
- Push and verify if needed. A commit stored in the current workspace is not necessarily present on the remote. Follow GitHub’s instructions for pushing changes, then confirm the remote branch shows the expected commit.
If a push fails, inspect the cause rather than rerunning the task. GitHub’s authentication guidance covers account and credential access. If the branch rejects a push, a repository’s protected-branch rules may require a pull request or another permitted route. Neither issue proves that the task’s files disappeared.
Choose the right place to resume
Use this comparison when you’re deciding whether to reopen a task, make a new one, or rely on a repository record.
| Option | What it lets you check | Main limitation | Choose it when |
|---|---|---|---|
| Reopen the original task | Its conversation, available workspace, status, and diff | It depends on that task’s workspace still being accessible | You need to inspect or continue its uncommitted changes |
| Start a new task | A separate workspace for a new piece of work | It does not automatically inherit another task’s uncommitted files | You intend to start fresh or have deliberately transferred the code |
| Use a Git commit and remote branch | A reviewable record of committed changes and, after a successful push, a copy in the remote repository | Uncommitted changes are not included; access and branch rules still apply | You need a durable handoff or want to continue across tasks and devices |
For a traveling workflow, the repository is the handoff point; the task is the place to continue a particular task’s work. Don’t choose between them as if they were interchangeable. Before relying on a commit, confirm that the expected files are included. Before relying on a push, verify that the remote branch contains it.
FAQ: recover a task without guessing
Will a new Codex Cloud task include files from my previous task?
No. Codex Cloud gives each task its own workspace, so starting another task does not automatically bring over uncommitted files from the earlier one. Open the original task to inspect its changes. If you need the work in a separate task, first preserve it through version control or another deliberate transfer, then confirm the new workspace contains the expected files.
What should I do to continue a paused Codex Cloud task?
Return to the original task instead of creating a replacement. Check its status, open the available diff, and confirm the files you expect are still there. If the saved environment is available, continue from that task and run the relevant checks. If the changes are missing, inspect the repository history and permissions before assuming the conversation can restore the workspace.
How long can I restore a saved Codex Cloud workspace?
The OpenAI documentation describes a limited recovery window for a saved virtual machine; it is not a promise that every file or task remains recoverable indefinitely. The documented window applies to VM state, not conversation history. Check the current Codex Cloud help page for its exact limit and conditions before relying on recovery, and commit important changes rather than treating the window as a backup.
How do I get Codex Cloud changes into GitHub?
Review the task diff and tests first, then commit the intended changes in the repository and push the commit using an authorized account or configured credential. A visible task result is not proof that a commit or push happened. If pushing fails, separate a missing commit from an authentication problem or a protected-branch rule; each requires a different check.
Separate cloud code work from iOS acceptance
Codex Cloud can help produce or edit code, but don’t assume its task environment is a Mac or includes Xcode. For an iOS project, first decide which work is code review and repository handoff, and which work needs the project’s actual native build and test environment. Apple’s Xcode documentation describes the toolchain; your project’s requirements determine whether you need it for the next acceptance step.
A useful split is:
- Cloud task: Inspect generated code, review the diff, update source files, and preserve changes in version control.
- Mac-based validation: Build, run, sign, or test the project when its delivery requirements depend on Apple’s development tools or a macOS environment.
- Repository handoff: Confirm that the right commit is available to the environment where you’ll perform native validation.
If your current device cannot run that required Mac workflow, a remote Mac can provide a separate macOS environment to test the project. It does not replace the need to verify what Codex changed or whether the code is committed. You can review MACCOME’s remote Mac options and decide whether they fit the build and test requirements you actually have. If you need to check availability for a particular setup, review the Mac rental options before planning your handoff.
A remote Mac is not the right answer for every project. If your code only needs repository review and the required checks run in your existing environment, adding another machine may be unnecessary. If native build, signing, or testing is part of delivery, relying only on a Codex Cloud task may leave that acceptance work undone. And if you need a long-running, stable local environment or physical hardware access, evaluate those requirements before choosing a short-term remote setup.
Before you leave the session, verify three things: the original task or intended workspace is identified, the diff and test status are understood, and important changes are committed and pushed if your workflow requires a remote copy. That gives you a concrete recovery path after a device change or dropped connection. For the remaining iOS work, decide from the project’s build and test requirements whether you need a Mac environment; use a remote Mac only when it solves that specific gap.