Hey devs! I started with a small JavaScript project and asked Codex Cloud to explain it. That gave the next request some context: when Codex identified search-boundary issues, I could continue the same conversation and ask for a fix.
Watch the setup, the three prompts, and the local repository check in How to Use Codex Cloud: From GitHub to Your First Pull Request:
The Cloud workflow is prepare → publish → start task. Older Codex Cloud tutorials may show the legacy experience. Official Cloud documentation
Before you start
- A ChatGPT account with Codex Cloud access in the workspace you're using.
- A GitHub repository you can connect, preferably a small project you understand.
- Existing tests, runnable examples, or a specific behavior you can check.
- Git and your project's runtime if you plan to review the changes locally.
Cloud requires ChatGPT sign-in. You don't need an API key. Accounts supporting email-and-password login require MFA before Cloud access; social-login and SSO requirements differ. Authentication
An environment holds the reusable repositories, dependencies, tools, and access settings. A task starts from that published setup and gets its own working files. Continue the same task when you want to keep its changes and conversation context.
1. Create a cloud environment
Open ChatGPT on the web or in the desktop app. In a new task, choose Work in → Cloud → Select environment → Create environment.
If you already have a suitable published environment, select it and skip to step 5. You can also manage environments through Settings → Codex Cloud → Environments.
Cloud selected in the Work in menu, with Choose environment available.
2. Connect GitHub and select the repository
Connect GitHub if prompted, then choose the repository you want Codex to work on.
When GitHub offers repository access choices, I usually select only the project I want to work on. Check the account, repository name, and access you're granting, then select Get started.
Choose the GitHub repository for the cloud environment, then select Get started.
Codex inspects the repository and prepares its tools and dependencies. Supply missing information or access when asked. For another project, follow its declared runtime versions and installation commands.
3. Read the setup report
Read the report to see which tools and dependencies Codex prepared. For my JavaScript project, it showed Node.js was available and the examples could run.
The setup report lists runnable examples and shows Save and publish.
Before publishing, check which commands ran, whether anything failed or was skipped, and whether the runtime matches your project. A larger app might also need a database or private registry.
If the report is unclear, this is a suggested follow-up:
List the setup commands you ran, their results, and anything still missing.
Explain whether this environment is ready for a coding task.
Running examples confirms they can execute in the environment. Behavior fixes still need tests that cover the problem you're trying to solve.
4. Publish the environment
Select Save and publish and wait for Environment published. Then return to Codex, choose Cloud, and select the published environment for your coding task.
Select Save and publish after reviewing the environment setup.
The Environment published confirmation below the setup report.
Saving stores configuration; publishing prepares the starting point for new tasks. To reopen an existing setup, use Settings → Codex Cloud → select the environment → three dots → Edit. Test later setup changes and select Republish. Existing tasks keep their state, so start a new task to use the updated setup. Saved-state behavior
5. Ask Codex to explain the project
My first prompt was:
explain this repo
The first prompt with a cloud environment selected.
Codex described the array, sorting, and search examples, then identified issues in binary search and jump search.
For your own first run, I'd make the request more specific:
Explain this repository to a developer joining the project.
Identify the main files, how to run it, and how to check it.
Name one small issue worth investigating. Do not edit files yet.
6. Request a focused fix
In the same task, I sent:
fix the issues
That worked with the preceding explanation as context. In a new task, describe the issue again. A more precise suggested request for this example would be:
Fix the binary-search and jump-search boundary issues you identified.
Keep the standalone examples working.
Add regression checks for empty arrays, single-item arrays,
missing targets, and targets in the final search block.
Run the relevant checks and report the commands and results.
Avoid unrelated refactoring or new dependencies.
One correction in the JavaScript example was binary search's inclusive upper bound: intArray.length became intArray.length - 1. For three items, valid indexes are 0, 1, and 2. A focused fix gives you a specific behavior to verify.
7. Inspect the changes and reported checks
Ask Codex to list the changed files, the commands it ran, and any failures or skipped checks. Read the diff alongside the command output so you can see what was actually covered.
Codex's fix summary and reported test results.
Inspect the test cases too. For a behavior fix, check whether the tests exercise the failing input and would detect the original problem.
8. Open a pull request
A fix in the cloud workspace doesn't automatically create a pull request. When you're ready to review the change on GitHub, ask:
create a pr
Open the returned link and read the description and diff. Check that the proposed changes address your request and avoid unrelated work.
The pull request page shows the proposed changes and review status.
For your own task, you could ask for a PR description containing the problem, fix, validation commands, and checks that couldn't run. Include “Do not merge it” if you want the workflow to stop for review.
Review GitHub's CI results separately from Codex's command summary. Run the relevant checks before merging, using the commands documented for your project.
Get the cloud changes locally
My local checkout didn't change when the pull request was created. Cloud tasks and local repositories have separate working files.
Fetch and check out the PR branch to review it before merging. After a reviewed PR is merged, you can instead pull the updated target branch.
For a branch in your repository's origin remote, with no local branch of that name yet, the commands look like this. Replace <pr-branch> with the source branch shown on the PR page:
git fetch origin
git switch --track "origin/<pr-branch>"
Commit or stash unrelated local edits before switching branches. If the PR is updated during review, fetch the update and confirm you're testing the same code as the latest diff. Run your project's tests and any checks specific to the changed behavior.
If you find a failure, return to the same task with the exact input, expected result, and actual result. Ask for a regression check and a rerun.
Keep important work in source control. By default, saved VM state is recoverable for up to seven days after you last start a turn or resume the task. It doesn't replace a commit or a saved output. VM state
Cheers, proflead ;)
Top comments (0)