Codex Cloud runs coding tasks in a remote environment. You can ask it to explain a project, edit files, run checks, and prepare a GitHub pull request while your computer is asleep.
For my walkthrough, I started with small JavaScript examples. That made it easy to understand the setup and follow the changes. My first request was explain this repo; once Codex identified issues, I continued in the same task with a fix request.
This guide follows that workflow from environment setup to reviewing a pull request and checking out the changes locally. You can follow the screen walkthrough in How to Use Codex Cloud: From GitHub to Your First Pull Request.
Understand the environment and the task
There are four pieces to the workflow:
Repository: your code on GitHub.
Environment: the reusable setup, including tools, dependencies, configuration, and access.
Task: a conversation with its own working files, starting from the published environment.
Pull request, or PR: proposed changes submitted through GitHub for review.
Prepare the environment, publish it, then start a task. Follow-up messages continue with that task’s files and context. Each new task gets a separate workspace, even when several tasks use the same environment.
OpenAI distinguishes the current Cloud workflow from Codex Cloud (Legacy). Older tutorials may show different setup screens or access rules. Cloud environment documentation
What you need
Start with a GitHub project you can connect and understand. Have a way to check the result: existing tests, runnable examples, or a clear expected behavior.
Cloud uses ChatGPT sign-in. If your account supports email-and-password login, OpenAI requires MFA for cloud access; social-login and SSO requirements differ. Authentication requirements
OpenAI’s feature comparison lists cloud chats for Plus, Pro, Business, and Enterprise/Edu. Workspace permissions also apply, and included usage has limits. Check the current plan comparison before subscribing for this workflow.
1. Create a cloud environment
Open ChatGPT on the web or in the desktop app. In the video, I open the sidebar’s three-dot menu and choose Codex. Near the prompt field, choose Work in → Cloud, open the environment selector, and create an environment.
If you already have a suitable published environment, select it and move on to the task.
The Work in menu with Cloud selected.
Connect GitHub if prompted, select your repository, and choose Get started. My GitHub connection was already set up, so I could select the project directly.
Choose the GitHub repository for the cloud environment, then select Get started.
Check the repository access you’re granting. For an organization-owned project, the connection needs the relevant organization permissions too.
2. Check the prepared setup and publish it
Codex inspects the project and prepares the environment. Read its report before continuing. In my JavaScript example, Node.js was available and the sample scripts ran without extra dependencies or services.
The setup report and Save and publish button.
A larger project may need a package installation, database, or configuration values. Compare the setup commands and runtime versions with its README and manifests. If a command fails, find the first error and resolve it before moving on.
If you need more detail, ask:
List the setup commands you ran and their results. Explain any failures, skipped checks, or missing configuration. Tell me what remains before this environment is ready.
Select Save and publish and wait for Environment published. Return to Codex, choose Cloud, and select the published environment to start your task.
Select Save and publish after reviewing the environment setup.
The Environment published confirmation.
Publishing makes the prepared setup available to new tasks. Application deployment is a separate step.
For later configuration changes, open Settings → Codex Cloud → select the environment → three dots → Edit. Test the updated setup, republish it, and start a new task to use it. Existing tasks retain their own state. Publishing and saved state
3. Ask for an explanation before an edit
My first message was:
explain this repo
The repository-explanation prompt in the selected cloud environment.
Codex described the array, sorting, and search examples. It also identified problems in the search code. Starting with an explanation gave the next request context.
For your own project, you can be more explicit:
Explain this repository to a developer joining the project. Identify the main files, how to run it, and how to test it. Point out one small issue worth investigating. Do not edit files yet.
Compare the answer with the project you know. If it misunderstands how the application starts or which files matter, correct that before requesting a change.
4. Request one focused change
I continued in the same task with:
fix the issues
Codex already had the previous explanation and its list of issues. In a fresh task, describe the problem and expected behavior again.
A more specific request helps keep the work manageable. For a search implementation, for example:
Fix the search boundary issues you identified. Keep the standalone examples working. Add checks for empty arrays, one-item arrays, absent targets, and targets in the final search block. Run the relevant checks and report failures or skipped checks. Avoid unrelated refactoring and new dependencies.
A boundary case sits at the edge of the normal input. For an array of length three, the valid indexes are 0, 1, and 2. An inclusive upper boundary should use intArray.length - 1; intArray.length points beyond the final item.
When reading a fix, follow the behavior through the code. Does the search inspect the final candidate? Does it stop when the target is absent? Does it handle an empty array?
5. Review the changes and run the checks
Ask Codex to summarize the changed files and give the exact commands it ran. Read the diff, which shows added and removed lines, and check that the changes match your request.
The task response includes a change summary and a test command.
Use your project’s documented checks. A standalone Node.js project might have a command such as:
node search.test.js
Read the tests as well as their output. For a search fix, useful cases include an empty array, one item, a missing target, and a target in the last block. A regression test should catch the original failure and pass after the correction.
Run the relevant checks yourself when possible. If a case fails, return to the same task with the command, input, expected result, and actual result. That gives Codex a specific problem to investigate.
For a UI change, also inspect the application in a local or preview environment. Command output alone cannot tell you whether the page looks or behaves correctly.
6. Create and review a pull request
Changes in the cloud workspace need to be published to GitHub before collaborators can review them there. Ask Codex to prepare the pull request:
create a pr
For a more detailed description, you can ask it to include the problem, changed behavior, validation commands, and any unresolved checks.
GitHub presents the proposed changes for review.
Open the returned link and check the source branch, target branch, changed files, and description. Review any CI results alongside the checks run in the task. GitHub’s mergeability status tells you whether the branches can merge cleanly; you still need to assess the code’s behavior.
If publishing fails, read the exact error. Check the GitHub connection, repository permissions, and relevant network configuration before retrying.
7. Bring the branch into a local checkout
Cloud work and your local checkout have separate files and branch state. Creating a GitHub PR doesn’t update the files on your computer.
To review a proposed change locally, fetch the remote branches and check out the branch shown in the PR. From your existing checkout, replace your-task-branch with that branch name:
git status git remote -v git fetch origin git switch --track origin/your-task-branch
The last command creates a local tracking branch. If the branch already exists locally, switch to it with git switch your-task-branch. Check for uncommitted work before switching.
Run the project’s checks in that checkout and compare the code with the PR diff. After a reviewed PR is merged, switch to the target branch and pull the merged changes instead.
For your first task, choose a change whose expected behavior you can explain. Prepare the environment, make the request, and review the returned files and checks before merging.
Cheers, proflead ;)
