Cloud tasks and GitHub

Back to the Codex learning hub

Goal and preparation

Cloud work runs in its configured environment; mobile Remote controls a connected host. Uncommitted computer edits, signed-in websites and node_modules do not appear in cloud simply because a project has the same name. Use an explicit repository branch and file inventory as the reproducible starting point.

Step 1: Prepare files the cloud can actually read

Extract the Small Steps pack. Take index.html, style.css, app.js, core.mjs and core.test.mjs from broken. Keep expected as a local answer reference, outside the starting repository. The broken Completed filter returns unfinished tasks, deliberately producing one failing test.

In GitHub New repository, choose your account, name it codex-cloud-lab, select Private and initialize a README. Use Add file → Upload files to place the five files at its root. Describe the commit as “Add broken Small Steps exercise” and save it to this new lab's starting branch. If account rules require a branch and PR, follow that process to land the materials first; keep production protections intact.

Confirm core.mjs is at the root, not accidentally inside broken, and files contain real code. Open visibleTasks and verify the reversed completed predicate. Record the displayed branch and latest commit; do not assume the default is main. The cloud selection must include the uploaded materials. Successful GitHub login alone does not establish that starting state.

Step 2: Connect the repository and create an environment

Open Codex cloud, confirm the ChatGPT account/workspace and follow Connect GitHub to select accessible repositories. Grant this first exercise access to codex-cloud-lab. Complete any required organization approval before expecting it in the list. GitHub identity and ChatGPT identity are distinct; signing into one does not authorize the other connection.

Create its environment in environment settings. The exercise needs no external package, API or key, only Node.js with node:test. Select an available compatible Node.js 22 or newer runtime through package-version settings. Put only the following version check in the setup script; the deliberately failing test belongs in the task, not setup where it could prevent the agent from starting.

node --version

Leave agent internet access Off for this exercise: all required files are in the repository. Setup networking and agent networking are different stages; successful installation does not imply unrestricted agent access. For a separate package-based project, use its lockfile and setup logs. Do not add dependencies or put a private token in README to solve this dependency-free lab.

Step 3: Verify the starting version, then repair

Select the environment and branch containing the materials, then submit this read-only request. Expect the directory, commit, five source files and one failing test. If all tests already pass, check whether you uploaded expected or selected a repaired branch; do not damage correct code just to match the article. Missing root files indicate a repository or upload-location problem to resolve first.

Inspect this Small Steps practice repository without changing files. Report the working directory, git commit, branch if available, and the five source filenames. Run node --test core.test.mjs. Explain the failing behavior from the test and core.mjs. Keep files unchanged and do not open a pull request yet.

After checking the response and logs, send the repair request in the same task. Limit it to the completed filter in core.mjs, preserving tests and other behavior. Deleting tests, weakening assertions or changing expected values is not the repair. If a larger rewrite is proposed, ask why a focused predicate correction is insufficient before expanding scope.

Fix only the reversed completed filter in core.mjs. Completed must return only finished tasks, Active only unfinished tasks, and All every task. Preserve order, input immutability and all existing tests. Remove any now-obsolete exercise comment. Run node --test core.test.mjs and show the final diff. Do not merge, deploy or open a PR until I review the result.

Step 4: Verify and prepare the PR

Expect all three tests to pass. The completed branch keeps tasks whose completed value is true, and the obsolete exercise comment is removed. Active and All remain unchanged; core.test.mjs should have no diff. Inspect the final diff and latest test run, not an earlier completion sentence. Request actual output if the answer only predicts success or omits the execution result.

Compare with the starting commit, not just uncommitted changes

Use the commit recorded in the first read-only inspection as the baseline. If the agent already committed changes within the task, a plain git diff can now be empty even though the task changed files. Review the complete difference from the starting point to the final result. If the baseline is missing, recover it from the task log rather than guessing a branch name. The request below is for inspection and does not itself create or merge a PR.

Use the commit recorded in our initial read-only inspection as the baseline.
If you cannot identify it, stop and ask me to recover that record.
Compare the final tracked tree against that baseline, including committed, staged and unstaged changes.
List untracked files separately. Confirm whether core.test.mjs is unchanged and explain every changed file.
Report the latest actual test command and result, or say not run.
Do not modify files, open a PR, merge or deploy.

When ready, use the task's PR action, confirm the repository, base branch and repaired head, and use the draft below. A PR requests review; it is not a merge or deployment. Resolve conflicts, pending checks or unrelated changes before deciding to merge. This exercise may stop at an unmerged PR for the testing and review lesson.

Title: Fix Completed filtering in Small Steps

Completed previously displayed unfinished tasks. It now displays only finished tasks while preserving Active, All, order and input data.

Baseline commit: [fill in the commit from the initial inspection]
Result checked: [fill in the final commit or task diff identifier]
Validation: [fill in command, exit code and actual pass/fail counts]
Browser verification: [performed / not run, with scope or reason]
Deployment: not performed.

Replace every bracketed field with your actual record. Report three passing tests only if that is what you ran, and mark unperformed checks as not run with a reason. The PR title and result description must match the final diff too. For visual acceptance, obtain the exact PR branch or commit in a separate folder and follow your first project: preserve any wanted practice data, use About this exercise → Reset practice data, select All tasks and confirm an empty list. Then add Read and Build, complete only Read, and verify Completed shows Read while Active shows Build. A working older local copy does not validate the new cloud changes.

Troubleshooting, stopping and next steps

For a missing repository, check owner, connection scope and organization approval. For failed initialization, read the first setup error and Node version. For a missing test file, check branch and root layout. For cloud/local disagreement, compare commits, files and latest tests. These are access, tool, material-location and version problems; resending the same prompt does not distinguish them.

Use the current task's available stop control and verify its stopped state, then inspect retained changes. Stopping does not undo an existing PR or GitHub mutation. An unmerged PR can be closed after review; merged work needs a targeted Git reversal, not chat deletion. Environment/UI steps are documentation-checked, while broken/reference tests were checked locally. This article does not claim to have created a reader's cloud task, PR or deployment.

Back to the Codex learning hub

Read the full description

GitHub to Cloud environment to Pull request

• AI tools
• Tutorials
• Codex