Codex Cloud can take a GitHub project from a prepared cloud environment to a pull request, but you still need to review the code and checks yourself. Connect a repository, inspect and publish its environment, give Codex a bounded task, then review the proposed changes in GitHub or check out the branch locally.
Before you connect GitHub
OpenAI lists Codex Cloud for Plus, Pro, Business, and Enterprise/Education plans. API-key access is not supported, and workspace permissions also apply. Check that your account and workspace can use the feature before preparing a repository. OpenAI’s feature table lists Codex Cloud eligibility and usage details.
Choose a project whose expected behavior and test commands you can assess. That makes it easier to give Codex a specific task and judge the result rather than accepting a plausible-looking change at face value.
Prepare and publish an environment
- Select the GitHub repository. In the documented web or desktop flow, open Work in → Cloud → Select environment → Create environment, choose the repository, connect GitHub if prompted, and select Get started.
- Review the setup. Codex inspects the project and prepares its environment. Read the setup report, including the runtime versions and commands, and resolve missing dependencies, access, or configuration before proceeding.
- Publish the environment. Review the configuration and publish it once the setup is ready. Publishing saves a reusable starting point for new tasks; it does not deploy your application. A new task starts in an isolated workspace based on that published environment. Existing tasks keep their own saved files and changes, so they do not automatically switch to a newly published setup. OpenAI’s cloud-environment guide describes setup, task workspaces, and saved state.
If you change the reusable setup later, test and publish that environment again before starting a new task that needs the changes.
Give Codex a bounded task
Start with the expected behavior, the relevant test commands, and any boundaries on unrelated edits or new dependencies. For a bug fix, name the failing case and what the corrected result should be.
In a JavaScript walkthrough published by HackerNoon, author proflead first asked Codex to explain the repository, then requested a focused fix for search-boundary issues. The example concerns a familiar off-by-one bug: for an array of three items, valid indexes are 0, 1, and 2, so an inclusive upper index is the array length minus one. That is a useful way to make a task testable, not a guarantee that Codex will produce a correct fix. Read proflead’s walkthrough.
Review the changes and pull request
Inspect the changed files and the full diff. Run the project’s documented tests, and check their inputs as well as their output. Then review the pull request’s source and target branches, description, and CI results. A clean merge status means GitHub sees no conflict with the base branch; it does not establish that the code behaves correctly.
Before accepting the change, confirm that the tests cover the behavior you asked for and that the diff contains no unrelated edits. If the pull request is ready for local review, check for uncommitted work before switching branches, then fetch and check out the proposed branch:
git status
git remote -v
git fetch origin
git switch --track origin/your-task-branch
Replace your-task-branch with the pull request’s branch name. Run the project’s tests in the local checkout before relying on the change.
Resources and saved task state
OpenAI’s default cloud VM resources differ by plan group. The documented values are:
| Plan group | vCPUs | Memory | Disk |
| Plus, Edu Plus | 2 | 8 GiB | 8 GiB |
| Pro, Business, Enterprise, Edu, Edu Pro | 4 | 16 GiB | 32 GiB |
OpenAI says saved VM state can be recovered for up to seven days after the last task turn is started or the task is resumed. Keep important work in source control: saved task state is not a substitute for commits. Cloud chats and local messages share the plan’s usage allowance, and cloud tasks may consume more; usage varies with the model and task. The resource and usage details help you judge whether a project fits the environment and your plan.
Credentials and network access
Environment variables and network secrets reach a task differently. OpenAI documents these two mechanisms:
| Method | What the program receives | Destination and condition |
| Environment variable | The value itself, passed directly to programs in the environment | Configure the required destination and credentials separately |
| Network secret | A placeholder; a proxy substitutes the credential for a request | The destination must be allowed, and substitution applies to HTTPS on port 443 |
Allowing a hostname does not provide credentials or grant permission to use the service. Check authentication separately from network access. OpenAI’s cloud-environment guide explains both credential mechanisms and network settings.
A cloud task does not automatically inherit your laptop’s files, processes, browser sessions, or VPN connection. OpenAI documents separately configured VPN access using Tailscale; access rules and the environment’s network settings must both be configured. Current documented cloud limitations include browser or computer use, GitLab, and self-hosted GitHub Enterprise Server.
A Reddit commenter, u/filopedraz, also cautions that a headless environment may lack the real services an application needs for testing. That is an individual user’s assessment, but it points to a practical check: make sure the cloud setup can reach the services your project’s tests depend on. The Codex community discussion.
