Codex Cloud runs a coding task in a hosted workspace prepared from your project repositories. The practical sequence is to authorize the intended GitHub repositories, create or select an environment, check its setup, publish it, and then start a bounded task. Review the changed files and test results before accepting the work. This guide follows OpenAI’s current documented environment workflow. Our account check did not include a published practice environment or a completed cloud task, so the setup sequence is documentation-based. It should not be read as a claim that a repository was connected or a pull request was created during this test.
Select the repository and environment deliberately
Open ChatGPT and sign in to the account intended for this project. The official cloud quickstart describes Work in > Cloud, then Select environment on the web or desktop. Use an existing authorized environment or choose Create environment.
Connect GitHub when prompted and grant access to the repositories needed for this exercise. Check organization approval if a workplace repository is absent. A personal account being signed in does not establish access to every organization repository.
Use a small, non-sensitive practice repository for the first run. Confirm the repository names and starting branch before setup. Creating an environment or connecting an account is a separate external action from reading a tutorial; use only resources you are authorized to configure.
Let setup run, then inspect its checks
OpenAI’s environment guide describes preparing repositories, tools, dependencies, and service access. Codex can inspect the project and prepare its workflow. Review what was installed and which setup checks ran.
Keep setup failures distinct from task failures. A missing private package, absent system dependency, or unavailable service can prevent a correct test from running. Record the failed command and the missing requirement, then repair the environment rather than asking a coding task to guess around it.
Review the setup and test results, save the intended changes, and select Publish. Wait for Environment published. An environment still in preparation is not the same as a published environment ready for tasks.
Configure network and credentials for the task
Use the environment’s documented network controls and secret settings for required HTTPS services. Grant the access the project actually needs. Do not paste a production secret into a source file or use a broad credential when a scoped practice credential is sufficient.
Check private registries, dependency downloads, API access, and integration tests separately. A setup command reaching a registry does not prove the task can reach every later service. Read the environment guide’s network and saved-state sections before relying on assumptions from a local machine.
Cloud work has its own filesystem. A file available on your laptop is not automatically present there. Commit the intended practice files or supply context through a supported route. Do not assume uncommitted local edits were transferred.
Start one bounded task
After publishing, choose Start a new task. For an existing environment, select it and send the task. Use a prompt with a concrete result and a narrow scope:
Read the repository instructions and the shipping tests. Find why an
order of exactly $50 is charged shipping. Make the smallest correction,
run the relevant tests, and show the changed files. Do not deploy,
merge, contact external services, or change unrelated files.The cloud task should report what it changed, what it checked, and any blocked checks. A hosted task being able to continue while your computer sleeps is useful, but it does not remove the need to inspect its output.
Retrieve and verify the changes
Review the diff and the test command in the completed task. Check the precise boundary case and neighboring behavior. Request a follow-up if the result is incomplete or the patch exceeds scope.
When ready, use the interface’s supported commit or pull-request path. Review the target repository and branch before creating an external artifact. In this article’s research, no cloud commit, pull request, or repository was created.
For local verification, obtain the proposed change through the supported workflow and test it in the intended checkout. Do not assume that a local folder already contains the cloud result. The code review guide explains how to turn a reported finding into an independently verified correction.
When a repository is missing
Check which GitHub identity is connected, whether the app has repository access, and whether organization approval is required. Then confirm the environment is associated with that repository. Repeatedly starting a task cannot repair missing repository authorization.
If setup succeeds but a task fails, inspect dependencies, network requirements, credentials, and the task’s actual working state. If local and cloud results disagree, compare revisions, environment versions, and test inputs. Use troubleshooting for separating startup, access, and execution problems.
Slack and issue-tracker entry points
OpenAI’s cloud documentation links its Slack integration. Treat a connected messaging or issue-tracker entry point as an additional integration requiring its own access and supported commands. It does not substitute for a prepared repository environment.
This guide did not test a Slack or Linear invocation and does not promise that a tracker action is available to every plan or workspace. Use the current integration documentation and your administrator’s setup before starting work from an external conversation. For tasks that only need your current local project, compare the app and CLI rather than configuring a hosted environment unnecessarily.