Codex Cloud lets you give a coding task to an agent running in a remote environment. It can read the project, edit files, run commands, and prepare changes for review on GitHub.
I started my walkthrough with small JavaScript examples. Asking Codex to explain the project first gave me enough context to follow up with a focused fix. You can use the same approach for your first cloud task.
The screen walkthrough is in the video below.
https://youtu.be/GPrPPNCu1Uw?embedable=true
Here's how to set up the environment, run a task, review the result, and get the changes onto your computer.
Understand what runs in the cloud
Your repository contains the code. A cloud environment holds the reusable setup: tools, dependencies, configuration, and access. Each task has its own working files, starting from that published environment.
The current flow is prepare the environment → publish it → start a task. Follow-up messages continue within the same task. OpenAI distinguishes this workflow from Codex Cloud (Legacy), so check which experience an older tutorial describes.
Cloud uses ChatGPT sign-in. The feature comparison lists cloud chats for Plus, Pro, Business, and Enterprise/Edu; workspace permissions also apply. Check the plan comparison and authentication requirements for your account before starting.
1. Connect a project and prepare its environment
Sign in to ChatGPT, open Codex, and choose Work in → Cloud → Select environment → Create environment. You can also manage environments under Settings → Codex Cloud → Environments.
Connect GitHub if prompted, select the project, and choose Get started. My GitHub connection was already set up, so I could select the project directly.
Start with a repository you understand. A small project with runnable examples is easier to assess than an unfamiliar application with several services. Check the repository permissions you grant, including any organization access requirements.
Choose the GitHub repository for the cloud environment, then select Get started.
Codex prepares the project and produces a setup report. For my JavaScript example, the report said Node.js was available and the sample scripts ran without extra dependencies or services.
The environment setup report and Save and publish button.
Read the report before continuing. Check runtime versions and commands against the project's README and manifests. A database, private package registry, or required configuration value may need attention during setup.
If a command fails, investigate the first error. Missing tools, unavailable hosts, and missing credentials need different fixes.
2. Publish the environment and start a task
Select Save and publish after reviewing the environment setup.
Select Save and publish and wait for Environment published. Return to Codex, choose Cloud, and select the published environment.
Publishing saves a prepared starting point for new tasks. It doesn't deploy your application.
To change the reusable setup later, open Settings → Codex Cloud → select the environment → three dots → Edit. Test the changes, republish, and start a new task to use the updated setup. Existing tasks keep their own state. Publishing and saved state
3. Ask for an explanation
My first message was:
explain this repo
Codex described the array, sorting, and search examples and identified issues in the search code.
For your own project, you can ask for more detail:
Explain the main files and how this project runs.
Find the documented build and test commands.
Point out one small issue worth investigating.
Do not edit files yet.
Check whether the answer matches what you know about the project. Resolve misunderstandings before asking Codex to make changes.
4. Request a focused fix
I continued in the same task with:
fix the issues
That message referred to the problems Codex had just listed. In a fresh conversation, specify the issue and expected behavior again.
For a search implementation, a more precise request could be:
Fix the search boundary issues you identified.
Keep the standalone examples runnable with Node.js.
Add regression checks for empty arrays, single-item arrays,
missing targets, and a target in a short final block.
Report the commands you ran, their results, and any blocked checks.
Avoid unrelated changes or new dependencies.
The details give you a clear scope to review. If a search operates over an inclusive index range, its upper boundary should be the array length minus one. For a three-item array, valid indexes are 0, 1, and 2.
Check the surrounding behavior too. Does the algorithm inspect the final candidate? Does it terminate when the target is absent? Does it handle an empty array?
5. Read the diff and test the change
Ask Codex for the changed files, a summary of the fix, and the commands it ran. Read the diff to check that the implementation matches the requested behavior.
The task response summarizes the changes and includes a test command.
Use the project's documented checks. For a standalone Node.js project, a test command might look like:
node search.test.js
Read the test inputs as well as the output. Regression tests should expose the original bug and pass with the correction. For a search fix, check empty arrays, single items, absent targets, and the final search block.
Reproduce the relevant checks before accepting the change. If something fails, send Codex the exact command, input, expected result, and actual result in the same task.
For interface changes, also open the application in a local or preview environment. Current cloud environments don't support browser or computer use.
6. Create a pull request
The cloud workspace and GitHub have separate state. To publish the proposed changes for review, ask:
create a pr
You can also request a description covering the problem, the fix, validation commands, and any checks that remain unresolved.
The proposed changes are presented for review on GitHub.
Open the returned link and check the source and target branches, diff, and description. Review any CI results. A branch that can merge without conflicts still needs a behavior review.
If publishing fails, read the error and check repository permissions, the GitHub connection, and network access. Retry once you understand which part failed.
7. Get the changes into your local checkout
Creating a PR doesn't automatically update the files on your computer. To review the branch locally, fetch it and check it out.
From your existing checkout, replace your-task-branch with the branch shown in the PR:
git status
git remote -v
git fetch origin
git switch --track origin/your-task-branch
The final command creates a local tracking branch. If that branch already exists locally, use git switch your-task-branch. Check for uncommitted work before switching.
Run the project's tests in the checkout you're reviewing. After a reviewed PR is merged, switch to its target branch and pull the merged changes instead.
Where Cloud helps and where local work fits better
Cloud is useful when the project can be prepared remotely and you want to leave a task running while your computer sleeps. A published environment also gives future tasks a reusable starting point.
The remote workspace doesn't automatically have your laptop's files, running processes, browser sessions, or VPN connection. Local Codex is a better fit when the task needs that access. The current handoff documentation also says a local Codex chat can't be moved into a cloud environment; start a cloud task with the relevant context.
Internet access and authentication are separate. Allowing a package-registry hostname doesn't supply its credentials. Configure required destinations and credentials during setup, test them, and republish the environment after changes.
For a private repository, confirm the account and connection have the required access, including organization rules. Review your account's data controls before connecting sensitive code.
Usage depends on the task and shares plan allowances with local messages. Check the current pricing and usage guide before planning a large workload.
Start with one behavior you can test and one small change you can read. Once that workflow makes sense, move on to a project with more setup requirements.
Cheers, proflead ;)